Mechanisms that

As a distributed cluster management tool, Kubernetes is an important task to ensure the security of the cluster. API Server is the intermediary for communication between components within the cluster and also the entry point for external control. So Kubernetes’ security mechanism is basically designed around protecting API Server. Kubernetes uses Authentication, Authorization and AdmissionControl to ensure the security of API Server

Authentication

  • HTTP Token authentication: Uses a Token to identify legitimate users

    • HTTP Token authentication is a way of representing a customer in a long, specially encoded string called Token that is hard to imitate. Tokens are long and complex strings, and each Token corresponds to a user name stored in a file accessible to the API Server. When the client initiates an API call request, it needs to put a Token in the HTTP Header

  • HTTP Base authentication: The user name and password are used for authentication

    • User name + : + Password The string encoded using the BASE64 algorithm is sent to the server in the HeatherAuthorization domain of the HTTP Request. After receiving the string, the server encodes it to obtain the user name and password

  • Strictest HTTPS certificate authentication: client authentication based on the CA root certificate signature

ⅰ. HTTPS Certificate Authentication:

ⅱ. Nodes to be authenticated

Two types of

  • Access by the Kubenetes component to the API Server: Kubectl, Controller Manager, Scheduler, Kubelet, kube-proxy
  • Kubernetes managed Pod access to containers: Pod (Dashborad also runs as Pod)

Safety instructions

  • The Controller Manager and Scheduler are on the same machine as the API Server, so they are directly accessed through the insecure port of the API Server, –insecure-bind-address=127.0.0.1
  • Kubectl, Kubelet, and Kube-proxy all require certificates for HTTPS bidirectional authentication when accessing API Server

certificate

  • Manual issue: The HTTPS certificate is issued through the CA of the K8S cluster
  • When kubelet accesses the API Server for the first time, the Controller Manager will generate a certificate for Kubelet. All subsequent accesses will be authenticated by the certificate

Ⅲ, kubeconfig

The kubeconfig file contains cluster parameters (CA certificate, API Server address), client parameters (certificate and private key generated above), and cluster context information (cluster name, user name). The Kubenetes component can switch to a different cluster by specifying a different Kubeconfig file at startup

Ⅳ, ServiceAccount

The container in Pod accesses the API Server. Because Pod creation and destruction are dynamic, it is not feasible to manually generate certificates for it. Kubenetes used the Service Account to authenticate Pod access to the API Server

ⅴ. The relationship between Secret and SA

Kubernetes designed a resource object called Secret, which is divided into two types: service-AccountToken for ServiceAccount, and Opaque for storing user-defined confidential information. The ServiceAccount contains three parts: Token, ca. CRT, and Namespace

  • The token is a JWT signed using the API Server private key. Server authentication for accessing the API Server
  • Ca. CRT, root certificate. Used by the Client to authenticate certificates sent by the API Server
  • Namespace: identifies the scope domain space of the service-account-token
kubectl get secret --all-namespaces 
kubectl describe secret default-token-5gm9r --namespace=kube-system
Copy the code

By default, each namespace has a ServiceAccount. If a ServiceAccount is not specified when a Pod is created, the ServiceAccount of the namespace to which the Pod belongs is used

conclusion