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

This article mainly introduces the example analysis of kubernetes API Server rights management, the article is very detailed, has a certain reference value, interested friends must read it!

API Server rights management application

Introduction of API Server access control mode

There are three kinds of API Server access control: Authentication (identity authentication), Authorization (authorization), and AdmissionControl (admission control).

Authentication:

When a client initiates an API request to a Kubernetes non-read-only port, Kubernetes authenticates the validity of the user in three ways. In kubernetes, there are three ways to verify whether a user has permission to operate api: certificate authentication, token authentication, and basic information authentication.

Certificate authentication

Set the startup parameter of apiserver:-- client_ca_file=SOMEFILE, the certificate for verifying client contained in the referenced file. If verified, the principal object in this verification record will be the username of the request.

Token certification

Set the startup parameter of apiserver:-- token_auth_file=SOMEFILE. The format of token file consists of three columns: token,username,userid. When using token as the authentication method, in the http request to apiserver, add a Header field: Authorization, and set its value to: Bearer SOMETOKEN.

Basic information authentication

Set the startup parameter of apiserver:-- basic_auth_file=SOMEFILE. If you change the password in the file, only restart apiserver to make it effective again. The basic format of the file contains three columns: passwork,username,userid. When using this as the authentication method, in the http request to apiserver, add a Header field: Authorization, and set its value to: Basic BASE64ENCODEDUSER:PASSWORD.

Authorization:

In Kubernetes, authentication and authorization are separate, and authorization occurs after authentication is completed, and the authentication process is to verify that the user who initiated the API request is who he claims to be. The authorization process determines whether the user has permission to execute the API request, so authorization is based on the result of authentication. The Kubernetes authorization module is applied to all HTTP access requests to APIServer (except read-only ports), and access to read-only ports does not require authentication and authorization. When APIServer starts, authorization_mode is set to AlwaysAllow mode by default, which is always allowed.

The Kubernetes authorization module examines each HTTP request and extracts the required attributes in the context of the request (for example, user,resource kind,namespace) to compare with access control rules. Any API request needs to be verified by one or more access control rules before it can be processed.

Currently, Kubernetes supports and implements the following authorization modes (authorization_mode), which can be selected by passing parameters when apiserver starts.

-- authorization_mode=AlwaysDeny

-- authorization_mode=AlwaysAllow

-- authorization_mode=ABAC

The AlwaysDeny mode blocks all requests (usually for testing). The AlwaysAllow mode allows all requests, and the default apiserver starts in AlwaysAllow mode). The ABAC (Attribute-Based Access Control, attribute-based access control) mode allows users to customize authorized access control rules.

ABAC mode:

Four attributes in an API request are used in the user authorization process:

The UserName:String type, which identifies the user who initiated the request. If no authentication or authorization operation is performed, the string is empty.

The ReadOnly:bool type that identifies whether the request is read-only (GET is read-only).

The Kind:String type that identifies the type of Kubernetes resource object to access. The Kind property is not empty when accessing API endpoint such as / api/v1beta1/pods, but the Kind property is empty when accessing other endpoint, such as / version,/healthz, etc.

The Namespace:String type that identifies the namespace where the Kubernetes resource object to be accessed is located.

For ABAC mode, you need to specify-- authorization_policy_file=SOME_FILENAME in addition to passing in the-- authorization_mode=ABAC option when apiserver starts. Each line of the authorization_policy_file file is a JSON object, which is an unnested map data structure that represents an access control rule object. An access control rule object is a map with the following fields:

The user string specified by user:--token_auth_file.

Readonly:true or false, if true, indicates that the rule applies only to GET requests.

Kind:Kubernetes built-in resource object types, such as pods, events, and so on.

Namespace: it can also be abbreviated to ns.

A simple access control rule file is shown below, with one rule per line defined.

{"user": "admin"}

{"user": "alice", "ns": "projectCaribou"}

{"user": "kubelet", "readonly": true, "kind": "pods"}

{"user": "kubelet", "kind": "events"}

{"user": "bob", "kind": "pods", "readonly": true, "ns": "projectCaribou"}

Note: the default field is equivalent to the zero value of this field type (empty string, 0focus false, etc.).

The rules are explained line by line as follows.

The first line shows that admin can do anything, regardless of namespace, resource type, or request type.

The second line shows that alice can do anything in namespace "projectCaribou", regardless of resource type or request type.

The third line indicates that kubelet has permission to read information about any pod.

The fourth line shows that kubelet has permission to read and write to any event.

The fifth line indicates that Bob has permission to read the information of all pod in namespace "projectCaribou".

An authorization process is a process of comparing whether the attributes in the API request match the corresponding fields in the access control rule file. When apiserver receives an API request, the properties of the request are determined, and if there is a property that is not set, apiserver sets it to a null value of that type (empty string, zero false, etc.). The matching rules are simple, as shown below.

If an attribute in the API request is null, it is specified that the attribute matches the corresponding field in the access control rules file.

If a field of the access control rule is null, it is specified that the field matches the corresponding property of the API request.

If the attribute value in the API request is not empty and a field value of the access control rule is not empty, the two values are compared, and if they are the same, they match, and vice versa.

The attribute tuple (tuple) of the API request matches all the rules in the access control rules file one by one. If there is one match, the match is successful. If not, the authorization fails.

Admission control:

Admission control admission controller is essentially a piece of admission code. In the process of request to kubernetes api, the sequence is first authenticated and authorized, then the admission operation is performed, and then the target object is operated. This access code is in apiserver and must be compiled into a binary before it can be executed.

When a request is made to the cluster, each admission control code is executed in a certain order. If an admission control rejects the request, the result of the entire request will be returned immediately and the user will be prompted for the corresponding error information.

In some cases, the admission logic may change the target object in order to apply the configuration of the application system. In addition, the admission logic also changes some of the resources related to the requested operation.

Action

In kubernetes, the prerequisite for some advanced features to function properly is to leave some access modules in the enable state. To sum up, for kubernetes apiserver, if the admission control module is not properly configured, it cannot be called a complete server, and some functions will not work properly.

Opening mode

There is a parameter in kubernetes apiserver: admission_control, whose value is an ordered list of admission modules connected by commas. Once set, a certain order of access module calls can be performed before the object is manipulated.

Module function

AlwaysAdmit: allow all requests

AlwaysDeny: disable all requests, mostly for test environments.

DenyExecOnPrivileged: it intercepts all requests that want to execute commands on privileged container. If your cluster supports privileged container and you want to restrict users from executing commands on these privileged container, it is highly recommended.

ServiceAccount: this plug-in automates serviceAccounts, which is highly recommended if you want to use ServiceAccount objects.

The description of serviceAccount is as follows: a serviceAccount adds the corresponding authentication information to the process running in pod. When this plug-in is enabled in the access module (enabled by default), then when pod creates or modifies it, he will do the following:

If pod does not have a serviceAccount attribute, set the serviceAccount property of the pod to "default"

Make sure that pod using de serviceAccount always exists

If LimitSecretReferences is set to true, discard the pod when the pod references the Secret object but not the ServiceAccount object

If the pod does not contain any ImagePullSecrets, the ImagePullSecrets of the serviceAccount is added to the pod

If MountServiceAccountToken is true, add a VolumeMount to the container in pod.

SecurityContextDeny: this plug-in will invalidate all the options defined in pod that uses SecurityContext. SecurityContext defines operating system-level security settings (uid, gid, capabilities, SELinux, etc.) in container.

ResourceQuota: it observes all requests and ensures that there are no exceptions to the container enumerated at the ResourceQuota object in the namespace. If you use the ResourceQuota object in kubernetes, you must use this plug-in to constrain container. It is recommended that this plug-in ranks last in the admission control parameter list.

LimitRanger: he observes all requests to make sure that there are no violations of defined constraints, which are defined in the LimitRange object in namespace. If you use the LimitRange object in kubernetes, you must use this plug-in.

NamespaceExists: it observes all requests, and if the request attempts to create a namespace that does not exist, the request is rejected.

Recommended plug-in order

-- admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount, ResourceQuota

Verification process

1. Some default attributes related to permission authentication are set in the initialization parameters of API Server:

Security listening port: SecurePort: 8443 read / write permissions, support x509 security certificate and x509 private key authentication

Non-secure listening port: InsecurePort: 8080 has no user authentication and authorization, and has read / write access

Authorization mode: AuthorizationMode: "AlwaysAllow"

Admission control plug-in: AdmissionControl: "AlwaysAdmit"

2. When API Server starts, you can set parameters related to permission authentication:

-- insecure_port Custom non-secure listening Port

-- secure_port custom security listening port

-- tls_cert_file sets the security certificate file

-- tls_private_key_file sets the private key file

This property is ignored when the cert_dir security certificate file and private key file are set. When the security certificate file and private key file are not set, apiserver automatically sets the

The public IP address bound to the port generates a self-enrollment certificate file and key respectively and stores them under / var/run/kubernetes

-- service_account_key_file service account file containing x509 public and private keys

-- client_ca_file client certificate file

-- token_auth_file token file

-- basic_auth_file basic information authentication document

-- authorization_mode authorization model

-- ahtuorization_policy_file authorization file

-- list of admission_control admission control modules

-- admission_control_config_file admission Control profile

3. Parse the input parameters and extract authentication information:

Public and private key file settings: check whether ServerAccountKeyFile is specified. If not, and TLSPrivateKeyFile is specified, determine whether the TLSPrivateKeyFile contains a valid RSA key. If so, use TLSPrivateKeyFile as a ServerAccountKeyFile.

Authentication information extraction: the username,userID,password (or token) is encapsulated into a map structure from the CSV file set by the parameter, and key is the struct with three attributes of username,value. Fetch user information from basicAuthFile, clientCAFile, tokenFile, serviceAccountKeyFile (serviceAccountLookup) to get an map array of authentication information.

Authorization information extraction: read the set authorization file, parse the string, and return an array of authorization information. (including username,group,resource,read only,namespace) Make the "cluster" Kinds be one API group (minions, bindings,events,endpoints). The "user" Kinds are another (pods,services,replicationControllers,operations).

Admission control plug-in: get all plug-in names and return to the admission control interface (execute all plug-ins)

4. The identity authentication information, authorization information, admission control plug-in as the configuration of Master, New Master.

5. Request for authentication:

Call the NewRequestAttributeGetter method of apiserver, extract authorization information from the request, and call the WithAuthorizationCheck method (authorization verification).

Call the NewRequestAuthenticator method of handler, extract the authencate information from Request, and call the AuthenticateRequest method (there are different verification methods for client certificates,token,basic auth).

Supplement

Authentication:

Token authentication, when making a request, add an Authorization:bearer token string to the request header. In the CSV file, the three columns are token,username,userid. Authentication succeeds when there is a line in the CSV that matches the requested Authorization.

Basic auth authentication, when a request is made, an Authorization:basic base64-encoded user:password string is added to the request header. In the CSV file, the three columns are password,username,userid. Authentication succeeds when there is a line in the CSV file that matches the requested Ahtuorization.

Certificate verification:

When API Server starts, it specifies the server digital certificate and key (if not specified, it will be automatically generated when server starts), and specifies the client ca file. When server starts, it parses the ca document, traverses the cert in it, and joins the certpool. Specify the authentication mode in the TLSConfig of Server: RequestClientCert is currently used (no mandatory authentication, no connection when there is no authentication, and other authentication is allowed), in addition to other authentication modes requireAndVerifyClientCert (forced check). Use ListenAndServeTLS (which takes the server digital certificate and key as parameters) to listen on the secure port.

API Server permission control operation (not added to namespace) test:

Start server: specify token authentication file, authorization method, authorization file

. / _ output/local/bin/linux/amd64/canary-apiserver-- logtostderr=true-- log-dir=/tmp-- Venture 4-- etcd_servers= http://127.0.0.1:4001-- insecure_bind_address=127.0.0.1-- insecure_port=8088-- secure_port=8442-- kubelet_port=10250-- service-cluster-ip-range=10.1.1.0/24-- allow_privileged=true-- runtime-config= "api/v1beta3=false"-- redis-addr=localhost:6379-- profiling=true-- token _ auth_file=token.csv-- authorization_mode=ABAC-- authorization_policy_file=abac.csv

Contents of Token file:

Abcdef,hankai,123456

Abcdefg,hk,123457

Abcd,admin,1234

Abc,hhh,111

Contents of the authorization file:

{"user": "admin"}

{"user": "hankai", "readonly": true}

{"user": "hhh", "resource": "apps"}

{"user": "hk", "readonly": true, "resource": "namespaces"}

Verify: admin (has access to read and write all resource)

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abcd"-k https://10.57.104.59:8442/api/v1/apps

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abcd"-k https://10.57.104.59:8442/api/v1/namespaces

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abcd"-dumbbell 1.json'- k https://10.57.104.59:8442/api/v1/namespaces

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abcd"-dumped appellation demo1.json'-k https://10.57.104.59:8442/api/v1/apps

Verify hankai (only read permission GET)

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abcdef"-dumped appellation demo1.json'-k https://10.57.104.59:8442/api/v1/apps forbidden

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abcdef"-dwindlers 1.json'- k https://10.57.104.59:8442/api/v1/namespaces forbidden

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abcdef"-k https://10.57.104.59:8442/api/v1/namespaces

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abcdef"-k https://10.57.104.59:8442/api/v1/apps

Verify hk (only GET rights to namespaces)

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abcdefg"-k https://10.57.104.59:8442/api/v1/apps

Forbidden

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abcdefg"-k https://10.57.104.59:8442/api/v1/namespaces

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abcdefg"-dwindlers 1.json'- k https://10.57.104.59:8442/api/v1/namespaces forbidden

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abcdefg"-dumped appellation demo1.json'-k https://10.57.104.59:8442/api/v1/apps forbidden

Verify hhh (have read and write rights to apps)

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abc"-dumped appellation demo1.json'-k https://10.57.104.59:8442/api/v1/apps

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abc"-k https://10.57.104.59:8442/api/v1/apps

Curl-X GET-H "Content-Type: application/json"-H "Authorization: bearer abc"-k https://10.57.104.59:8442/api/v1/namespaces

Forbidden

Curl-X POST-H "Content-Type: application/json"-H "Authorization: bearer abc"-dumbbell 1.json'- k https://10.57.104.59:8442/api/v1/namespaces

Forbidden

Note: later, you only need to specify namespace in each column of the abac.csv file to realize the operation permission of user to the specified namespace.

Added: TSL client certificate authentication

Test with self-generated certificate: generate server.crt,server.key,ca.key,ca.crt using openssl. When Server starts, pass-- tls_cert_file=server.crt-- tls_private_key_file=server.key-- client_ca_file=ca.crt

. / _ output/local/bin/linux/amd64/canary-apiserver-- logtostderr=true-- log-dir=/tmp-- Venture 4-- etcd_servers= http://127.0.0.1:4001-- insecure_bind_address=7.0.0.1-- insecure_port=8088-- secure_port=8442-- kubelet_port=10250-- service-cluster-ip-range=10.1.1.0/24-- allow_privileged=true-- runtime-config= "api/v1beta3=false"-- redis-addr=localhost:6379-- profiling=true-- tls _ cert_file=server.crt-tls_private_key_file=server.key-- client_ca_file=ca.crt-- token_auth_file=token.csv-- authorization_mode=ABAC-- authorization_policy_file=abac.csv

When requesting, you can use-cacert to specify the client certificate (you can specify the path of the client certificate by modifying the configuration file of opnessl, or import the client certificate in the browser) curl-X GET-- cacert ca.crt-H "Content-Type: application/json"-H "Authorization: bearer abcd"-k certificate to achieve authentication.

The above is all the contents of the article "sample Analysis of kubernetes API Server Rights Management". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.