Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What new features are added to Kubernetes1.5

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "what features are added to Kubernetes1.5". The editor shows you the operation process through an actual case, and the operation method is simple, fast and practical. I hope this article "what features are added to Kubernetes1.5" can help you solve the problem.

The official release of Kubernetes1.5 fixes many known problems, further enhances federation-related features, renames PetSet to StatefulSet, renames ScheduledJobs to CronJobs, adds a command kubectl to operate federation, and so on.

Background introduction

In Kubernetes1.5, several new startup parameters related to authentication / authorization have been added to kubelet, which are:

Authentication related parameters:

Anonymous-auth parameter: whether to enable anonymous access, you can select true or false. The default is true, which means anonymous access is enabled. Authentication-token-webhook parameter: use tokenreviewAPI for token authentication. Authentication-token-webhook-cache-ttl parameter: webhook token authentication cache response time. Client-ca-file parameter: x509 certificate authentication is used. If this parameter is set, the authentication file set by the client-ca-file parameter is found. Any request can only be accessed normally if the corresponding authentication exists in the authentication file.

Authorization related parameters:

Authorization-mode parameter: the authorization mode of kubelet. You can choose AlwaysAllow or Webhook. If set to Webhook, SubjectAccessReviewAPI is used for authorization. Authorization-webhook-cache-authorized-ttl parameter: the cache duration of the authorized content when webhook is authorized. Authorization-webhook-cache-unauthorized-ttl parameter: when webhook is authorized, there is no cache duration of the authorized content. Authentication

The default anonymous-auth parameter is set to true, that is, anonymous authentication can be performed. Requests for kubelet API are carried out anonymously, and the system uses the default anonymous user and default user group to access it. The default user name is "system:anonymous" and the default user group name is "system:unauthenticated".

Anonymous requests can be disabled, so you need to set the kubelet startup parameter: "- anonymous-auth=false". If the request is not authenticated, it will return "401 Unauthorized".

You can use x509 certificate authentication (X.509 format is the most common signing certificate format). At this point, you need to set the kubelet startup parameter: "- client-ca-file", provide the authentication file, and authenticate through the authentication file. You also need to set the api server component startup parameters: "- kubelet-client-certificate" and "- kubelet-client-key". In the authentication file, a user can belong to multiple user groups, such as the authentication generated by the following example:

Openssl req-new-key jbeda.pem-outjbeda-csr.pem-subj "/ CN=jbeda/O=app1/O=app2"

This example creates the csr authentication file, which acts on the user jbeda, who belongs to two user groups, app1 and app2.

Token authentication can be enabled, when you need to enable API related to the api server component authentication.k8s.io/v1beta1 through the command "- runtime-config=authentication.k8s.io/v1beta1=true". You also need to enable the "- authentication-token-webhook", "- kubeconfig" and "- require-kubeconfig" parameters of the kubelet component.

Kubeconfig parameter: sets the path to the kubelet profile, which is used to tell the kubelet component the location of the api server component. The default path is.

Require-kubeconfig parameter: this is a Boolean parameter, can be set to true or false, if set to true, then means to enable the kubeconfig parameter, from the kubeconfig parameter set in the configuration file to find the api server component, if set to false, then means to use another kubelet parameter "api-servers" to find the location of the api server component.

In the kubernetes source code, there is an incorrect comment:

Func NewKubeletServer () * KubeletServer {versioned:= & v1alpha1.KubeletConfiguration {} api.Scheme.Default (versioned) config:= componentconfig.KubeletConfiguration {} api.Scheme.Convert (versioned,&config, nil) return&KubeletServer {KubeConfig: flag.NewStringFlag ("/ var/lib/kubelet/kubeconfig"), RequireKubeConfig: false, / / in 1.5, default to trueKubeletConfiguration:config,}}

The default setting for the RequireKubeConfig parameter here is false, but what is written in the comment is really true.

When token authentication is enabled, kubelet calls TokenReview API for token authentication.

Here is an example of an kubeconfig file format:

Clusters:-name: name-of-remote-authn-servicecluster:certificate-authority: / path/to/ca.pem # verify the authentication file for remote services server: https://authn.example.com/authenticate # remote service access https path users:-name: name-of-api-serveruser:client-certificate: / path/to/cert.pem # authentication file used by the webhook plug-in client-key: / path/to/key. Pem # key file corresponding to authentication file current-context: webhookcontexts:- context:cluster: name-of-remote-authn-serviceuser: name-of-api-severname: webhook

An example of authentication request format is as follows:

{"apiVersion": "authentication.k8s.io/v1beta1", "kind": "TokenReview", "spec": {"token": "(BEARERTOKEN)"}}

The successful authentication responses are as follows:

{"apiVersion": "authentication.k8s.io/v1beta1", "kind": "TokenReview", "status": {"authenticated": true, "user": {"username": "janedoe@example.com", "uid": "42", "groups": ["developers", "qa"], "extra": {"extrafield1": ["extravalue1", "extravalue2"]}

The failed authentication response is as follows:

{"apiVersion": "authentication.k8s.io/v1beta1", "kind": "TokenReview", "status": {"authenticated": false}} authorization

Any request will not be authorized until it is successfully authenticated, including anonymous authentication requests. The default authorization mode is AlwaysAllow, which means that any request is allowed. In fact, requests for API require more fine-grained segmentation and authorization for the following two reasons:

Although anonymous user requests are allowed, the API that anonymous users can access should be restricted.

Although authenticated user requests are allowed, different authenticated users should be able to access different API, and not all authenticated users can only access the same API.

To control API permissions, you need to enable API related to the api server component authorization.k8s.io/v1beta1 through the command "- runtime-config= authorization.k8s.io/v1beta1 = true", set the authorization mode parameter "- authorization-mode" to Webhook, and then enable the "- kubeconfig" and "- require-kubeconfig" parameters of the kubelet component. The role of these two parameters has been described in detail in the above authentication section, which will not be introduced here.

The Kubelet then calls the SubjectAccessReviewAPI of the api server component to determine which request requires authorization control.

The request action type is divided according to the HTTP access type, as shown in the following table:

HTTP verb request verbPOST createGET, HEAD getPUT updatePATCH patchDELETE delete

Resource access requests are divided according to different request paths, as shown in the following table:

Kubelet API Resource name Sub-Resource name / stats/* nodes stats/metrics/* nodes metrics/logs/* nodes log/spec/* nodes specall others nodes proxy

For resource access requests, the namespace and API group attributes are always null at access time, and the attribute value of the resource name is the node object name where the kubelet resides.

If you want kubelete API to have access control, you also need to make sure that the api server component has enabled the "- kubelet-client-certificate" and "- kubelet-client-key" parameters

Kubelet-client-certificate parameter: client authentication file path

Kubelet-client-key parameter: client key file path

Also ensure that the client is authorized to access the following properties:

This is the end of verb=*, resource=nodes,subresource=proxyverb=*, resource=nodes,subresource= statsverb=*, resource=nodes,subresource=logverb=*, resource=nodes,subresource=specverb=*, resource=nodes,subresource=metrics 's introduction to "what features are added to Kubernetes1.5". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report