This blog address: https://security.blog.csdn.net/article/details/130034953
1. Authentication security configuration
1.1, X.509 client certificate
X.509 client certificate is currently the most commonly used authentication security configuration method for users. It can also be called HTTPS certificate authentication. It is a two-way digital certificate authentication method based on CA root certificate signature. By default, Kubernetes enables this parameter configuration.
The three kube-apiserver startup parameters related to X.509 client certificates are:
⬤ client-ca-file: Specify the CA root certificate file as /etc/kubernetes/pki/ca.pem, with a built-in CA public key, used to verify whether a certificate is issued by a CA.
⬤ tls-private-key-file: Specify the API Server private key file as /etc/kubernetes/pki/apiserver-key.pem.
⬤ tls-cert-file: Specify the API Server certificate file as /etc/kubernetes/pki/apiserver.pem.
If the user uses kubeadm to deploy Kubernetes, kubeadm will automatically call openssl to generate certificates and related keys. Once the above three parameters are configured for kube-apiserver, it means that the HTTPS authentication method is enabled. At this time, if you access the cluster externally, you will be https://masterIP:6443/apiprompted Unauthorized access, so the cluster can only be accessed if the client has configured authentication information.
1.2. OIDC Token
OpenID Connect (OIDC) tokens are currently commonly used in mainstream public cloud platforms, and are an authentication method based on OAuth2. The main extension of OIDC to OAuth2 is reflected in the ID Token (ID Token), which is a JSON Web Token (JWT) signed by the server and returned together with the Access Token (Access Token) during authentication.
The flowchart of OCID authentication is as follows:
2. RBAC authorization mechanism
After the API Server authentication is passed, the credentials (username, ID, group) are used as the first-level input of the authorization module, and the resources, paths, and behaviors requested by the user are used as the second-level input. The authorization module is responsible for verifying the above inputs. Then enter the next verification stage of the process, that is, the admission controller. If it fails, it will return an HTTP 403 Forbidden error response message.
For the authorization mode, the most widely used in the industry is基于角色的访问控制（Role-Based AccessControl，RBAC）
RBAC policies contain the following core concepts:
⬤ Resource: refers to the resources in Kubernetes, such as Pod, Service, etc.
⬤ Role: Operations performed on the Resource, such as create, update, delete, etc. on the Pod.
⬤ Entity: Represents an application, which can be a user, group or service account.
⬤ Role Binding: Bind Role to Entity, indicating that an Entity is run on a specified Resource and a set of operations is performed.
It should be noted here that, in terms of Role and Role Binding, Kubernetes defines two scope types:
⬤ Cluster scope: Cluster Role and Cluster Role Binding.
⬤ Namespace scope: Role and Role Binding.
How to use the above two types of resources must be determined according to specific needs.
Example:
# 为应用程序建立服务账户资源
kubectl create namespace coolapp
# 查看创建的服务账户
kubectl --namespace=coolapp create serviceaccount myappid
# 创建Role，该Role只能在coolapp命名空间中查看和列出Pod
kubectl --namespace=coolapp create role podview --verb=get --verb=list --resource=pods
# 查看Role
kubectl --namespace=coolapp describe role/podview
# 创建Role Binding，将Role podview绑定至名为myappid的应用程序中
kubectl --namespace=coolapp create rolebinding mypodviewer --role= podview --serviceaccount=coolapp:myappid
# 查看Role Binding
kubectl --namespace=coolapp
3. Access controller
After the user request is authenticated and authorized by the API Server, it enters the admission controller link. As the name implies, the admission controller considers the access of the requested resources such as Deployment, Pod, Service, DaemonSet, and StatefulSet. Compared with the above mentioned The API Server authentication and authorization mechanism that we have learned, the admission controller is a more fine-grained resource control mechanism, which supports many advanced functions of Kubernetes, such as Pod Security Policy (Pod Security Policy), Security Context (Security Context), service account ( Service Account), etc.
The admission controller is actually a piece of code that intercepts user requests after authentication and authorization but before Kubernetes resource objects are persisted. The cluster administrator can complete the startup by specifying the value of the parameter item in the kube-apiserver configuration file --enable-admission-plugins. If not specified, the default is used --enable-admission-plugins=NodeRestriction. The NodeRestriction admission controller restricts the Node and Pod objects that the kubelet can modify.
Example:
--enable-admission-plugins= NodeRestriction，MutatingAdmissionWebhook,ValidatingAdmissionWebhook
The admission control process is mainly divided into two phases, the first phase runs the change admission controller, and the second phase runs the verification admission controller. Note that some of Kubernetes' admission controllers are both mutation admission controllers and validation admission controllers. If any admission controller in the first stage rejects the request, the entire request is rejected and an error is returned to the end user. When all the above two-stage verifications are passed, the requested metadata is persisted to the etcd component.
Pod security policy is a resource at the cluster level. It mainly provides fine-grained permission control during the creation and update phase of Pod. It is defined as an admission controller in Kubernetes. Cluster administrators can specify it in the kube-apiserver configuration file --enable-admission-plugins=NodeRestriction,PodSecurityPolicyto complete the startup.
The Pod security policy resource defines a set of conditions that Pods must follow when running and the default values of related fields. Only Pods that meet these conditions will be accepted by Kubernetes. In addition, after the Pod security policy is defined, it needs to be authorized by RBAC before it can be used normally.
Four, Secret object
Kubernetes uses Secret objects to hold sensitive information such as passwords, tokens, and SSH keys. Compared with putting sensitive information into the yaml file or container image defined by the Pod, using the Secret method is more secure and flexible. This method is also a key management method commonly used by developers. The Secret content can be a string or a file, and user operations on Secret mainly include two behaviors: transmission and access.
In the process of passing to the container, it is mainly carried out by mounting the host file system. Kubernetes supports passing Secrets to Pods by mounting volumes. When a temporary volume is mounted, it means that Secrets are not written to disk but are written in memory, so it is more difficult for attackers to obtain Secret content. In addition, the Secret content cannot be queried using kubectl decribeor docker inspect.
When accessing Secret, users usually use the following two methods:
⬤ Access Secret in the container.
⬤ The kubelet component accesses the Secret.
In the first way, if the attacker gains access to the container, he docker execor she can kubectl execthen obtain the Secret. For this type of attack, we can increase the difficulty for attackers to obtain information by running fewer tools in the container, such as prohibiting cat, vim, sh, etc.
The second method, by adding a NodeRestriction admission controller, restricts the kubelet to only access the Secrets scheduled to its node Pod, which can avoid excessive kubelet access rights.