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

K8S security mechanism

Kubernetes's security framework transmits security, authentication, authorization, and access control using RBAC authorization, how we, as a user, authorize different colleagues to access the cluster, such as developer colleagues, which resources and namespaces can be accessed, test which resources colleagues can access, and how we restrict them.

I. the security framework of K8S

You need to go through three hurdles to access the resources of K8S cluster: authentication, authentication and admission control.

If ordinary users want to access the cluster API Server securely, they often need a certificate, Token or user name + password. Pod access, such as the Dashboard of the ingress controller Ui, requires ServiceAccount, mainly to enable the container to access the API, that is, all interactions are through API. This may be done by a person through kubectl, or your program may call API, but all these require authorization.

The K8S security control framework is mainly controlled by the following three stages, each of which supports plug-ins and enables plug-ins through API Server configuration.

Authentication authentication Authorization authentication Admission Control admission control

In the previous words, that is, each stage is plug-in design, you can develop your own plug-ins and integrate these into the steps to achieve relevant access control, so you don't need to modify the original code to add. Therefore, many of the K8s design principles are designed on the basis of extensibility, allowing users to customize some things and integrate them as much as possible.

Next, take a look at a picture, which is some of the stages of visiting API.

From the above kubectl, API, UI, the API that visits k8sAPIMagi K8s provides a lot of interfaces.

These are all provided by Apiserver, and also support different functions to complete related processing, related authentication, and then there are three layers of authorization built into API. The first layer is authentication, the second layer is authentication, and the third layer is access control. After passing, you can access related resources. These resources are all called from ETCD, and some state information is stored.

Transmission security:

Now K8s has been changed to https for access, that is, no matter whether you are deployed in kubeadm or binary, he suggests that you use https for full stack communication, bid farewell to 8080 and use 6443.

Certification:

After API receives the request from the user, he will first authenticate. There are three things that can be done on this side of the authentication.

Three types of client authentication:

HTTPS certificate authentication: digital certificate authentication based on CA certificate signature, that is, the certificate signed by K8sMagi CA can be used as a certificate carried by your client access. It will help you authenticate. This is a way to extract whether you have the authority to access from this certificate.

HTTP Token authentication: use a Token to identify the user.

HTTP Base authentication: user name + password authentication, which is based on an authentication of http itself, but this is rarely used because of the low security factor.

The first level is to identify which certificate you entered with, or the token logo, to see if I can be trusted here, to see if I have this token, whether I have the relevant authorization, that is, if I have this token here, if not, it is not allowed to pass, and then the following will not be carried out again. If it is passed, for example, if the token has been created locally, if there is, it will be released for you to make the next judgment. That is, the second level authorization.

Authorization:

RBAC (Role-Based Access Control, role-based access control): responsible for completing the Authorization work. That is, it will check that your accessor does not meet the permissions, so it will judge you in this place. If you come to this identity, although you have this identity, but do not have this permission to access this resource, you will not be allowed to pass.

There are many types of support for authorized resources

Admission control:

To put it simply, the development will design some advanced functions directly by plug-in, that is, the access controller is a collection of plug-ins, in which there are some advanced features, all of which are implemented as plug-ins. If you don't enable these plug-ins, then you will not be able to use this function, which is the third level, that is, your request will be controlled by your plug-in access. Admission control will give you the method of verifying the implementation of the request, whether this plug-in is enabled or not, but in most ways, the default plug-in is enabled, and it is only allowed to request related resources after startup. Because it enables the plug-in, it will fail if it is not started.

Adminssion Control is actually a list of admission controller plug-ins, and requests sent to API Server need to go through each admission controller in this list. If the plug-in checks and fails, the request is rejected.

Recommended plug-ins above version 1.11:

-- enable-admission-plugins=\

NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,ResourceQuota

Use RBAC authorization

RBAC (Role-Based Access Control, role-based access control), which allows policy to be dynamically configured through Kubernetes API. That is, even if the configuration takes effect immediately, there is no need to restart the service.

Role

Role: Grant access to a specific namespace

ClusterRole: authorizes access to all namespaces

Role binding

RoleBinding: bind a role to a principal (that is, subject)

ClusterRoleBinding: bind cluster roles to principals

Principal (subject)

User: user

Group: user group

ServiceAccout: service account

To be a permission management system, there are two parts, the first is who is the object, the user that is created, and the second is the permission group, such as creating a development group, what permissions the development group has, and what permissions the development group can access. This is also in order to facilitate the management of these permissions to divide this permission group. It is very troublesome for each user to create a permission for him. Just add the user to this group directly, for example, open up and set permissions for him. He is a group of guest users, and he can only view some things in this group, but he is a development group. He has some development rights for some projects, and the administrator goes in and adds another development group on this management page. In this way, he will have the authority of the development group.

In fact, K8s is the same as what I just said. The user is the principal, who will access it, and then the permission group is the role, defining a set of permissions. If the user wants to attach the user to the permission set and attach a permission group to the development, it is called role binding. The role is divided into roles and cluster roles, and the cluster role is authorized by the cluster namespace.

That is to say, K8s has a namespace, so it is divided into a single namespace and all namespaces. The setting of this permission set, ClusterRole, is to authorize all namespaces, that is to say, to add a user to this permission role, which means that it can access all namespaces and related permissions.

Example: authorize default Namespace Pod read permissions for zhaocheng users

For example, you can only view some resources running in the default space of pod, such as svc. Logs do not have permission to view. When your probation period expires, you will be given some permissions and do some related operations.

Achieving this goal requires the following three steps

Using K8S CA to issue client Certificate to generate kubeconfig Authorization File

Create a RBAC permission policy

Ca.crt and Ca.key are the certificates that need to be issued.

[root@k8s-master ~] # ls / etc/kubernetes/pki/apiserver.crt apiserver.key ca.crt front-proxy-ca.crt front-proxy-client.keyapiserver-etcd-client.crt apiserver-kubelet-client.crt ca.key front-proxy-ca.key sa.keyapiserver-etcd-client.key apiserver-kubelet-client.key etcd front-proxy-client.crt sa.pub uses K8S CA to issue client certificate [ Root@k8s-master ~] # cd demo/ [root@k8s-master demo] # mkdir rbac [root@k8s-master demo] # cd rbac/ [root@k8s-master rbac] # rz-Erz waiting to receive. [root@k8s-master rbac] # lscert.sh cfssl.sh config.sh rbac.yaml [root@k8s-master rbac] # cat cfssl.sh wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64wget https://pkg.cfssl.org/R1.2/cfssljson_ Linux-amd64wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64chmod + x cfssl*mv cfssl_linux-amd64 / usr/bin/cfsslmv cfssljson_linux-amd64 / usr/bin/cfssljsonmv cfssl-certinfo_linux-amd64 / usr/bin/cfssl-certinfo [root@k8s-master rbac] # sh cfssl.sh

Then here we bring the script for issuing our certificate. Note here that the CN of the issuing user here refers to the user name of the issuing user, that is to say, K8s uses this CA to authenticate, it not only validates whether the certificate issued by me, but also verifies the user name in it, that is, whether the CN field is authorized, which is equivalent to the authentication piece. O is the user group, and you can also restrict this permission based on this user group.

[root@k8s-master rbac] # chmod + x cert.sh [root@k8s-master rbac] # vim cert.sh cat > ca-config.json

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.