A Kubernetes cluster security

1.1 Security Mechanism

Kubernetes realizes cluster security control through a series of mechanisms, including authentication and authorization of API Server, access control mechanism and Secret mechanism to protect sensitive information, etc. Cluster security has the following objectives:

  1. Ensure that the container is isolated from its host.
  2. Limit container interference with infrastructure or other containers.
  3. The principle of minimum permissions – Limit the permissions of all components reasonably, ensuring that a component only does what it is authorized to do, and limiting the scope of an individual component’s permissions by limiting its capabilities.
  4. Define boundaries between components.
  5. Divide the roles of common users and administrators.
  6. Allow assigning administrator privileges to ordinary users if necessary.
  7. Allow applications that have Secret data (Keys, Certs, Passwords) to run in a cluster.

API Server authentication management

2.1 Authentication Security

Kubernetes cluster all resources access and change are through Kubernetes API Server RESTAPI to achieve, so the key point of cluster security lies in how to identify and authenticate the client identity (Authentication). And the subsequent Authorization of access.

The Kubernetes cluster provides three levels of client authentication.

  1. HTTPS certificate authentication: the strictest bidirectional digital certificate authentication mode is based on the CA root certificate signature.
  2. HTTP Token authentication: Uses a Token to identify legitimate users.
  3. HTTP Base authentication: The user name and password are used for authentication.

2.2 PRINCIPLES of HTTPS Authentication

This method requires a CA certificate. The CA is a trusted entity in the PKI system, known as a TrustedThirdParty (TTP). One of the important conditions for CA to be a trusted third party is that CA’s behavior is non-repudiation. As a third party, rather than simply a superior, one must be able to hold the trusted person accountable.

A CA verifies the public key information of another person through a certificate, which is signed by the CA. If the user loses because of the trust certificate, the certificate can be used as effective evidence to hold the CA liable. It is because of its commitment to assume responsibility that CA is also called a trusted third party.

In many cases, cas and users are independent entities. As a service provider, CAS may cause losses to users due to quality of service problems (for example, errors in public key data released). The certificate is bound with the public key data and the identity information of the corresponding private key owner, and has the digital signature of CA. The CA name is also included in the certificate so that the dependent party can find the CA’s public key and verify the digital signature on the certificate.

CA authentication involves many concepts, such as root certificate, self-signed certificate, key, private key, encryption algorithm, and HTTPS.

Kubernetes CA authentication includes the following steps:

\

  1. The SERVERS of the HTTPS communication parties apply for a certificate from the CA. The CA is a trusted third-party organization. It can be a recognized authoritative enterprise or the enterprise itself. Enterprise internal systems generally use their own authentication system. The CA sends the root certificate, server certificate, and private key to the applicant.
  2. HTTPS Clients apply for a certificate from the CA, and the CA sends the root certificate, client certificate, and private key to the applicant.
  3. The client sends a request to the server, and the server sends the server certificate to the client. After receiving the certificate, the client uses the private key to decrypt the certificate and compares the messages in the certificate using the public key authentication information in the server certificate. For example, the client compares whether the domain name and public key are the same as the messages just sent by the server. If they are the same, the client recognizes the server.
  4. The client sends the client certificate to the server. After receiving the certificate, the server decrypts the certificate using the private key, obtains the public key of the client certificate, and authenticates the certificate information to check whether the client is valid.
  5. The client encrypts information with a random key and sends the encrypted information to the server. After an encryption scheme is negotiated between the server and client, the client generates a random key. The client encrypts the random key using the negotiated encryption scheme and sends the random key to the server. After the server receives the key, all the contents of the communication between the two parties are encrypted by the random key.

\

The above describes the communication process of the bidirectional authentication SSL protocol. In this case, both the server and the user are required to have certificates. For one-way SSL authentication, the client does not need to have a CA certificate. For the preceding step, you only need to delete the process of authenticating the client certificate on the server. When the symmetric password scheme and symmetric call key are negotiated, the password sent by the server to the client is not encrypted.

2.3 PRINCIPLES of HTTP Token Authentication

HTTP Token authentication is a way of identifying a customer using a long, specially encoded string that is hard to imitate: Token. In general, a Token is a very complex string. For example, the data after signing a string with a private key can be regarded as a Token. In addition, each Token corresponds to a user name, which is stored in a file accessible to the API Server. When a client makes an API call request, it needs to put a Token in the HTTP Header so that the API Server can identify legitimate and illegitimate users.

2.4 MECHANISM of HTTP Base Authentication

Typically, HTTP is stateless and can be identified between the browser and the Web server through cookies. Desktop applications (such as Sina desktop client, SkyDrive client, command line program) generally do not use cookies if they need to communicate and authenticate with the Web server. HTTP Base authentication is required. In this authentication mode, the string encoded with “User name + colon + Password” using the BASE64 algorithm is sent to the server in the Header Authorization domain of the HTTP Request. The server decodes the string to obtain the user name and password. Then the user is authenticated.

API Server authorization management

3.1 Overview of Authorization Management

When a client initiates an API Server call, the API Server performs user authentication and then user authorization, that is, determines whether an API call is valid based on authorization policies. Authorizing legitimate users and then authenticating them when they access is an important part of a permission and security system.

Authorization grants different access rights to different users.

Currently, API Server supports the following authorization policies (set using the API Server startup parameter –authorization-mode) :

  1. AlwaysDeny: denies all requests and is generally used for testing.
  2. AlwaysAllow: Allows all requests to be received, if the cluster does not require an authorization process, which is also the default configuration of Kubernetes.
  3. Attribute-based AccessControl (ABAC) : indicates that user requests are matched and controlled using user-configured authorization rules.
  4. Webhook: Authorize users by invoking external REST services.
  5. RBAC: role-based AccessControl.
  6. Node: is a proprietary mode for controlling access to requests from Kubelet.

Upon receiving the request, the API Server reads the data in the request and generates an access policy object. If certain attributes (such as Namespace) are not included in the request, the values of these attributes will be set to different default values depending on the attribute type (for example, an empty string for a string attribute; Set false for Boolean properties; Set 0 for numeric type properties). Then the access policy object is matched with all the access policy objects in the authorization policy file. If at least one of the access policy objects is matched, the request is authenticated. Otherwise, the API calling process is terminated and an error call code is returned to the client.

Four ABAC authorization mode

4.1 ABAC Authorization Policy

When ABAC mode is enabled on API Server, you need to specify the path and name of the authorization policy file (–authorization-policy-file=SOME_FILENAME). Each line in the authorization policy file is set as a JSON object of the Map type. This is called an “access policy object.” The specific authorization policy is determined by setting the apiVersion, KIND, and Spec attributes in the access policy object.

Among them, the apiVersion current version for abac. Authorization. Kubernetes. IO/v1beta1; Kind is set to Policy; Spec specifies the detailed policy Settings, including the subject property, resource property, and non-resource property fields.

  • Main properties
    • User (user name) : a string. The user name is derived from the Token file (the file in which the –token-auth-file parameter is set) or the value of the user name in the basic authentication file.
    • Group: When system: Authenticated is set to all authenticated requests, and when System :unauthenticated is set to all unauthenticated requests.
  • Resource properties
    • API Group (API Group) : A string indicating which API groups to match, such as extensions or * (matching all API groups).
    • Namespace: a string indicating that the policy allows access to the resources of a namespace, such as kube-system or * (matching all namespaces).
    • Resource: A string of API resource objects, such as Pods or * (matching all resource objects).
  • Non-resource attribute
    • NonResourcePath: URL path of a non-resource object class, such as /version or /apis. * matches all request paths of non-resource object classes. /foo/* matches all subpaths of /foo.
    • Readonly: Boolean that, when true, allows only GET requests to pass.

4.2 ABAC Authorization Algorithm

The API Server performs ABAC authorization as follows: After receiving a request, the API Server first identifies the attributes of the policy object carried by the request, and then matches these attributes one by one according to the policies defined in the policy file to determine whether authorization is allowed. If at least one match is successful, the request is authorized (though it may still fail on subsequent authorization checks).

Common policy configurations are as follows:

  • To allow all authenticated users to do something, you can write a policy that sets the group property to System :authenticated.
  • To allow all unauthenticated users to do something, set the policy’s group attribute to System :unauthenticated.
  • To allow a user to do anything, set the POLICY’s API Group, Namespace, Resource, and nonResourcePath properties to “*”.

4.3 Use kubectl authorization mechanism

Kubectl uses API Server’s/API and/APIS endpoints to get version information. To verify the object sent to the server by kubectlcreate/update, kubectl needs to query OpenAPI, and the corresponding URL path is/OpenAPI /v2.

When using ABAC authorization mode, the following special resources must be explicitly set through the nonResourcePath property:

  • / API, / API /*, /apis, and /apis/* during API version negotiation.
  • Get /version from the server using the kubectlversion command.
  • / swaggerAPI /*

When using Kubectl operations, you can set the log level to 8 if you want to view HTTP requests sent to the API Server.

4.4 Common ABAC Examples

More ABAC reference: Attached 007.Kubernetes ABAC License.

5 RBAC authorization mode

See Appendix 006.Kubernetes RBAC License