Access control of Kubernetes API

Translated from official documents

The user uses kubectl or REST to request access to the API and client library. Both human users and service accounts can authorize access to the API. When the request reaches the API, it goes through several steps.

Transmission security

In a typical Kubernetes cluster, the API Server is located on port 6443. API Server presents the certificate. This certificate is usually self-signed, so $USER/.kube/configthe root certificate on the user's machine usually contains the API Server certificate. This root certificate is used to replace the system's default root certificate when specified. This certificate is usually automatically written when you create the cluster $USER/.kube/config. If the cluster has multiple users, the creator needs to share the certificate with them.

Certification

When the TLS connection is established, the HTTP request enters the authentication step. As shown in step 1 in the figure above . The cluster creation script or the cluster administrator configures the API Server to run one or more authentication modules. These modules are detailed here .

The input to the authentication step is the entire HTTP request, however, usually only the header and/or client certificate are checked.

The authentication module includes client certificate, password, plaintext token, self-service token and JWT Token (used by service account).

You can specify multiple authentication modules. At this time, each module tries authentication in order until one of them passes authentication.

If the request cannot be authenticated, it is rejected with HTTP status code 401. Otherwise, the user is authenticated as a specified, usernameand the user name can be used for decision-making in subsequent steps. Some authenticators also provide user group authentication.

Although Kubernetes is used usernameto make access control decisions and log requests, it does not have user objects, nor does it store usernames or other user-related information in its object store.

Authorization

After the request is authenticated, it must be authorized. As shown in step 2 in the figure above .

The request must include the user name of the requester, the requested action, and the object affected by the action. If there is an existing policy stating that the user has the right to complete the requested action, the request is authorized.

For example, if Bob has the following strategy, he can only read projectCaribouthe pod information of the namespace:

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

If Bob makes the following request, this request is authorized to allow:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

If Bob requests to write to an object in this namespace, his authorization is denied. If he requests to read resources in other namespaces, it is also rejected.

Kubernetes requires the use of REST attributes to interact with existing organizations (the O in the root certificate) or cloud provider access control system. It is important to use the REST format because these control systems may interact with APIs other than the Kubernetes API.

Kubernetes supports multiple authorization modules such as ABAC mode, RBAC mode and Webhook mode. The administrator configures the authorization module used by API Server when creating a cluster. If more than one is configured, Kubernetes will check each one, and if any module authorizes the request, the request can proceed. If all modules reject the request, the wondering request is forbidden. (HTTP status code 403)

For more about Kubernetes authorization, see Authorization Overview

Access control

The admission control module is a software module that can modify or reject requests. In addition to the attributes available to the authorization module, the admission control module can access objects that are being created or updated. They act on objects that are being created, deleted, updated, or connected (proxy), but not read.

You can configure multiple admission controllers and call them one by one in sequence.

As shown in step 3 in the figure.

Unlike the authentication and authorization modules, if it is rejected by any admission control module, the request is immediately rejected.

In addition to rejecting objects, the admission controller can also set complex default values ​​for fields.

The available admission control modules are described here .

After the request passes through all admission controllers, it will be verified using the verification routine of the corresponding API object and then written to the object storage ( step 4 in the figure ).

API Server IP and port

API Server can actually serve two ports:

1. Local port:
   • Used for testing and bootstrap, and other master node components communicate with API server
   • Non-TLS
   • The default port is 8080, --insecure-portparameter modification
   • The default IP is localhost, --insecure-bind-addressparameter modification
   • Request to bypass the authentication and authorization module
   • The request is processed by the admission control module
   • Protected by the need to access the host
2. Secure port
   • Use as much as possible
   • Use TLS. --Tls-cert-file parameter and --tls-private-key-file parameter to set the certificate
   • Default port 6443, -secure-port parameter modification
   • The default IP is the IP of the first non-localhost network card, modify -bind-address
   • The request is processed by the authentication and authorization module
   • The request is processed by the admission control module
   • Authentication and authorization module operation