Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to understand Kubernetes authentication and authorization", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "how to understand Kubernetes authentication and authorization" bar!

Authentication and authorization are two important basic requirements when setting up a product Kubernetes cluster. In this article, let's go through some details that can help the Kubernetes environment make a good plan.

For example, you have now triggered a command to create a POD by entering a yaml file into kubectl (kubectl create-f pod.yaml). This command is sent to the secure api-server port (http://) and the authentication flow begins to take effect. Note that if you are using an insecure port (http://) for api-server, authentication cannot be applied. (http://) ideally, unsafe ports (http://) should be avoided in production environment settings.

Here are the authentication approaches that can be used in Kubernetes that will be mentioned in this article.

Customer certificate verification

To use this scenario, api-server needs to be turned on with the-client-ca-file= option.

CA_CERTIFICATE_FILE must include one or more certification authorities that can be used to validate client certificates presented to api-server. The / CN of the client certificate will be used as the user name.

Token-based authentication

To use this scenario, api-server needs to be turned on with the-token-auth-file= option. TOKEN_FILE is a csv file, and each user entry has the following format: token,user,userid,group.

Group's name is random.

Examples of token files:

A very simple way to generate tokens is to run the following command:

The challenge for token-based authentication is that tokens are indefinite and any changes to the token list require a restart of api-server.

Basic certification

In order to use this scheme, api-server needs to be enabled using the-basic-auth-file= option. HTTP_AUTH_FILE is a csv file, and each user entry has the following format: password,user name,userid. Currently, any fix to AUTH_FILE requires a restart of api-server.

Open ID

Open ID support is also available, but it is still in the experimental stage.

Keystone

Keystone support is also available, but it is still in the experimental stage. If you want to integrate keystone with LDAP or dynamic directory services, use the keystone authentication method. In order to use this scenario, api-server needs to open the service with the-experimental-keystone-url= option.

After the authentication is successful, the next step is to find out which actions are allowed for the authenticated user. Currently, Kubernetes supports four authentication strategy schemes. Api-server needs to be turned on using the-authorization-mode= option.

Always deny

This strategy denies all requests.

Always allow

This policy allows all requests.

Attribute-based access control

ABAC allows flexible user-specific authorization policies. When api-sever is enabled with the-authorization-policy-file= option, the policy file for ABAC needs to be specified. Currently, any changes to the policy file require a restart of api-server.

A sample ABAC policy file is shown below:

In the above example, each line in the policy file is a JSON object and specifies a policy. This is a brief description of the policy object from the Kubernetes document page.

Version control feature-allows conversion formats for multiple versions and policies.

Api version, string type: the valid value is "abac.authorization.kubernetes.io/v1beta1".

Kind, string type: valid value is "policy".

Specification attribute-is a mapping with the following attributes:

Object-oriented matching attributes:

User, string: the user string is either from-token-auth-file or from the common name of the certificate file (CN). If you specify a user, it must match the authenticated user. * matches all requests.

Group, string: if you specify group, it must match the authenticated user in groups. * matches all requests.

Resource matching attribute

ApiGroup, string type: API group, such as the extended version. * match all APIgroup.

Namespace, string type: namespace string. * match all resource requests.

Resource, string type: resource, such as pods. * match all resource requests.

Non-resource matching attributes:

NonResourcePath, string type: matches all non-resource request paths (for example, / version,/apis). * match all non-resource requests. / foo/* and / foo/, and its subpaths.

Read-only, Boolean: when true, this means that the policy applies only to fetch, list, and monitor operations.

Webhook

Call up an external RESTful authorization service.

The choice of authentication and authorization mechanisms depends on your requirements. In my experience, however, I have found that the flexible combination of certificate-based authentication methods, keystone (LDAP) based authentication methods, and ABAC based authentication policies provides the necessary functionality to foster a Kubernetes environment.

Thank you for your reading, the above is the content of "how to understand Kubernetes authentication and authorization". After the study of this article, I believe you have a deeper understanding of how to understand Kubernetes authentication and authorization, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.