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

Today, I will talk to you about how to analyze the access control in K8s security. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Guide: access control is not only an important part of cloud native security, but also a necessary and basic security reinforcement means for K8s cluster in multi-rent environment. In K8s system, access control is divided into three important components: request authentication, authentication and run-time admission admission control. In this article, the author will lead you to understand the basic definition and usage of these three parts, and give the best practices of security reinforcement in multi-rent environment.

1. Kubernetes API request access control

Everyone knows that access control is an important part of cloud native security. It is also a basic security means that a Kubernetes cluster must adopt in a multi-tenant environment.

Then conceptually, it can be abstractly defined as who can do what operations on what resources under what conditions. The resources here are the resource models we are familiar with in Kubernetes: Pod, ConfigMaps, Deployment, Secrets, and so on.

Kubernetes API request

The above figure describes a process from the initiation of a Kubernetes API request to its persistence into the repository.

First of all, let's take a look at the initiation of the request, which is divided into two parts:

The first part is the process of human-computer interaction. It is a very familiar request process for apiserver with kubectl.

The second part is the interaction between the business logic in Pod and apiserver.

When our apiserver receives the request, the access control process will be started. There are three steps:

Authentication authentication phase: determine whether the requesting user is a legitimate user who can access the cluster. If the user is an illegal user, apiserver returns a 401 status code and terminates the request

If the user is legal, our apiserver will enter the second stage of access control, Authorization: authentication phase. During this phase, apiserver determines whether the user has permission to perform the requested operation. If the operation is not authorized, apiserver returns the status code of 403 and terminates the request as well

If the user has the right to do this, the access control will enter the third phase: AdmissionControl. During this phase, apiserver's admission controller determines whether the request is a security-compliant request. If the final verification passes, the access control process will end.

At this point, our request will be transformed into a corresponding change request for Kubernetes objects, which will eventually be persisted to ETCD.

2. User model in Kubernetes authentication Kubernetes

For authentication, we first need to determine who is the initiator of the request. And finally through the authentication process to convert it into a system-identifiable user model for later authentication, then let's take a look at the user model in Kubernetes.

1. Kubernetes does not have its own user management ability.

What is user management capability? We cannot create and delete a user instance through API, as we did with Pod. At the same time, we cannot find the corresponding storage object for the user in ETCD.

2. Users in Kubernetes are usually set by requesting credentials

How is the user model generated in the access control process of Kubernetes? The answer lies in the requester's access control credentials, that is, the certificate in the kube-config we usually use, or the ServerAccount introduced in Pod. After the Kubernetes authentication process, apiserver converts the identity of the user in the credentials in the request into the corresponding user models such as User and Groups. In the subsequent authentication operation and audit operation process, apiserver will use the modified user model instance.

3. The request authentication methods supported by Kubernetes mainly include:

Basic certification

Under this authentication method, the administrator will place the whitelist composed of Username and Password on the static configuration file read by apiserver for authentication. This method is generally used in test scenarios and is not recommended and cannot be extended in terms of security.

X509 certificate authentication

This method is more commonly used in apiserver. First of all, visitors will use the client certificate issued by the cluster CA or add the client certificate issued by the credit CA in the apiserver Client CA to access apiserver. After receiving the request, the apiserver server will carry out the handshake process of TLS. In addition to verifying the validity of the certificate, apiserver also verifies information such as the request source address of the client certificate. X509 authentication is a relatively secure way to enable two-way authentication, which is not only the default authentication method between Kubernetes components, but also the access credential often used in the kube-config corresponding to kubectl clients.

Bearer Tokens (JSON Web Tokens)

Service Account

OpenID Connect

Webhooks

The Tokens in this way is in the form of general JWT, which contains a variety of meta-information such as the issuer, the identity of the user, the expiration time and so on. Its authentication method is also a basic process of private key signing and public key verification. Token-based authentication is also widely used, such as Service Account, which is often used in Kubernetes Pod applications, in which a signed JWT Token is automatically bound to request apiserver.

In addition, apiserver also supports Token authentication based on OpenID protocol, which can connect to a specified external IDP through the configuration of apiserver, and manage IDP through open source services such as Keycloak,Dex. Requesters can log in and authenticate on the original identity authentication service in a familiar way, and finally return a corresponding JWT token for the later apiserver authentication process.

In addition, you can also use Webhooks to send the requested Token to the specified external service for Token verification.

X509 certificate authentication

For a cluster certificate system, the certification authority (CA) is a very important certificate pair. It will be placed by default in the / etc/Kubernetes/pki/ directory on the cluster Master node. The certificates used for communication between all components in the cluster are actually issued by the cluster root CA. There are two important fields related to identity credentials in the certificate: one is CN and the other is O.

In addition, the certificate can be parsed through the openssl command. As you can see on the right side of the above figure, the corresponding information can be viewed through the O and CN fields in Subject.

Each of the above component certificates has its own specified Common Name and Organization bindings for specific roles. This setting allows each system component to bind only the role permissions within its own functional scope. As a result, the permissions of each system component are minimized.

Certificate issuing API

The Kubernetes cluster itself provides API for certificate issuance, and during the cluster creation process, cluster installation tools such as kubeadm will call the apiserver corresponding interface based on different CSR signing requests. At this point, apiserver will create the corresponding issuing request instance in the form of this csr resource model according to the request. The issuing instance created at the beginning will be in the status of pending, and the csr will not be in the status of approved until approved by the authorized administrator, and the corresponding certificate of the request will be issued.

You can view the corresponding certificate content information through the commands on the right side of the figure above.

Issue user certificate

First of all, developers need to generate the private key through certificate tools such as openssl, then create the corresponding x509 csr request file, specify user user and group group in the subj field, and finally create K8s csr instance through API and wait for administrator approval.

For the cluster administrator, he can read the cluster root CA directly and issue the certificate through the x509 csr request file, so it does not need to define or approve the csr instance. The last line in the figure above is an example of openssl issuance. In the command, you need to specify the file path of csr and ca.crt, as well as the expiration time information of the certificate issued.

In addition, various cloud vendors will also generate the corresponding cluster access credentials based on the login users and the target cluster, which is convenient for users.

Service Account

In addition to certificate authentication, Service Account is also a widely used method in apiserver. For Service Account, it is the only APIService access credential in K8s that can be managed through API, and other features can be seen in the figure above.

The figure also shows some examples of using kubectl to add, delete, modify and query Service Account API. At the same time, we can manually create the corresponding secret of its token for the existing serviceaccount, and interested students can perform the operations in the Kubernetes cluster.

Then take a look at the use of Service Account.

First of all, you can view the specified secret corresponding to serviceaccount through the get secret-oyaml command, where the token field is the authenticated token in JWT format encoded by base64.

When deploying an application, we can declare the Service Account name we need to use through the serviceAccountName field in template-> spec-> containers. Note that if the established ServiceAccount does not exist during the Pod creation process, the Pod creation process will be terminated.

In the generated pod template, you can see that the ca,namespace and authentication token in the secret corresponding to the specified serviceaccount will be mounted to the specified directory in the container as a file. In addition, for the Pod that has been created, we cannot update the ServiceAccount content that has been mounted.

Generate kubeconfig

Kubeconfig is an important access credential used by users to connect to the Kubernetes cluster locally. Next, let's introduce the configuration and use of kubeconfig.

Use kubeconfig

3. Kubernetes authentication-RBAC

When a request is considered to be a legitimate user after completing apiserver authentication, how can the user access which resources in which namespace in the cluster, and what can be done with these resources?

This is accomplished by Kubernetes authentication, the second step of access control. Apiserver supports a variety of authentication methods. In this section, we mainly introduce the recommended authentication method RBAC in security.

Three elements of RBAC authentication

The first element is Subjects, that is, the subject. It can be a natural person such as a developer or a cluster administrator, a system component process, or a logical process in Pod

The second element is the API Resource, which is the access target corresponding to the request. In Kubernetes cluster, that is, all kinds of resources

The third element is Verbs, which corresponds to what operations can be carried out for the requested object resources, including additions, deletions, modifications and queries, list, get, watch and so on.

Here, for example, suppose there is a legally authenticated user Bob who requests a Pods under a namespace of list, and the authentication semantics of the request are changed to: Can Bob list pods? Where Bob is the Subject,list in the request is the corresponding request action Action, and pods is the corresponding request resource Resource.

RBAC permission granularity

The above describes the three elements of the RBAC role model, and under the entire RBAC policy definition, you also need to bind this role to a specific control domain. This is the familiar namespace of Kubernetes. Through namespace, you can limit Kubernetes api resources to different scopes. This helps us logically isolate users in a multi-tenant cluster.

The above example can be changed to User A can create pods in namespace B. It is important to note that if no permission binding is made, RBAC will deny all access.

Usually RBAC does fine-grained access control to apiserver, but this fine-grained is a relative concept, and RBAC is a model-oriented binding. It cannot be bound to a specific object instance in namespace, let alone to any field of a specified resource.

In terms of the granularity of access control by RBAC, it can be refined to the subresources level of Kubernetes api. For example, for a visitor, we can control his access to the nodes/status model under the specified namespace.

RBAC-Role

Then it introduces the specific binding permissions and objects of RBAC.

The first is the role Role, which defines what the user can do on the specified Kubernetes namespace resource. For example, you can specify read-only permissions for pod in a namespace, and you can also define a namespace administrator permission that has all permissions to operate on all object resources under this namespace.

As shown in the figure above, it is a definition template orchestration file for Role, where the resource field defines which resources the role can access, and the verbs field defines the permissions for which operations the role has. In apiGroups, you need to specify the apiGroups name of the target resource, which can be queried through the official API document. If the specified Group is core, the apiGroups in the role template can be left empty.

RBAC-RoleBinding

When we have finished defining a role under namespace, we also need to establish a binding relationship between it and the principal using the role under namespace, here we need a RoleBinding model. Using RoleBinding, you can bind the permission model corresponding to Role to the corresponding Subject.

For example, you can bind pod read-only permissions in a namespace named test to users test1 and test2 as well as proc1. You can also bind namespace test read-only permissions to test1 users in tech-lead group, so that users test2 and proc1 do not have get namespace permissions.

Then take a look at the corresponding RoleBinding orchestration file template.

The role we need to bind is declared in the roleRef field, and a binding can only specify a unique Role. The object we want to bind is defined in the subject field, which can be User,Group or Service Account. It supports binding multiple objects at the same time.

RBAC-ClusterRole

In addition to defining the permission model in the specified namespace, you can also define a cluster dimension permission model through ClusterRole. In a Cluster instance, you can define permission usage permissions in the cluster dimension. For example, resource permissions such as PV and Nodes that are not visible in namespace can be defined in ClusterRole, and the actions to operate these resources are also the operations supported in Role, such as add, delete, modify and query, list, watch and so on.

The following figure shows the ClusterRole orchestration file template:

The ClusterRole orchestration file is almost exactly the same as Role, except that the definition of permissions for all cluster dimensions is not supported in ClusterRole.

RBAC-ClusterRoleBinding

Also on the basis of ClusterRole, you can bind it to the corresponding Subject body. The ClusterRoleBinding model instance can help us bind ClusterRole to specific Subject objects on all the namespaces of the cluster.

For example, you can bind the list permissions of all namespace to administrators admin1 and admin2 whose group is sre or devops.

Compared with the RoleBinding,ClusterRoleBinding template definition, it is only different in the permission object model definition in namespace and roleRef, and the other definition format is the same.

RABC-Default ClusterRoleBinding

From what we have learned above, we know that RABC will deny all access without any permission binding. So how do our system components request each other?

In fact, when the cluster is created, the client certificates of the components of the system, their respective roles and environment objects will also be created to meet the necessary permission requirements for the interaction between component businesses.

Here are a few preset cluster roles:

How to set up the verbs in the role?

Through the above study of RBAC, we should have a certain understanding of the model definition in RBAC in Kubernetes, but in some complex multi-tenant business scenarios, how to define the corresponding action strategy for each API model in the permission template still needs a certain theoretical and practical basis. For an application developer, kubectl may be more intuitive and familiar, and here are some correspondence between kubectl operations and RBAC.

For example, when we want to edit a deploy, we need to add permissions such as get and patch to Deployment resources in the corresponding role template. If you want to exec into a pod, you need to add get permissions to pod and create permissions to the pod/exec model in the corresponding role templates.

IV. The use of Security Context CVE-2019-5736

According to the statistical results on docker hub, 82.4% of the mainstream business images are started by root users. Through this survey, we can see that the related use of Security Context is not optimistic.

Kubernetes Runtime security policy

Through the above analysis results, we can see that if we can configure enough secure run-time parameters for the business container, it is very difficult for attackers to take advantage of it. So what runtime runtime security hardening should we do when deploying the business containers in the Kubernetes cluster?

First of all, we should follow the principle of minimizing permissions. Except for the system permissions necessary for business operation, all other permissions can be removed.

In addition, you can configure the security of the business container at run time by setting the Security Context parameter in the pod or container dimension.

In addition, the security configuration of the container can be forcibly verified during the Admission phase of the apiserver request by enabling Pod Security Policy.

In addition to the opening of PSP, the common configuration parameters are also listed in the figure above.

Pod Security Policy

Because the PSP policy is relatively complex, here are some considerations for using it.

First of all, you can directly manipulate the security policy example of PSP through API. For example, the configuration parameters supported by PSP policy on the left of the above figure include privileged container, system capabilities, runtime user id, file system permissions and other configurations. You can also find a detailed description of each parameter in the official documentation.

The function of PSP is to verify the security parameter configuration based on this policy before the business container is running, and prohibit the Pod from running if it does not meet the security policy.

Finally, we need to pay attention to a few points in the use of PSP, as shown on the right side of the figure above.

Fifth, summary-multi-rent safety reinforcement

Finally, in the multi-rent environment, how to use the native security capabilities of Kubernetes to do security reinforcement to make a summary of the best practice.

After reading the above, do you have any further understanding of how to interpret the access control in K8s security? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.