This page provides an overview of controlling access to the Kubernetes API.

Users access the Kubernetes API using kubectl, client libraries, or by making REST requests. Both human users and Kubernetes service accounts can be authorized for API access. When a request reaches the API, it goes through several stages, illustrated in the following diagram:

用户通过kubectl工具，客户端库，或REST请求来访问k8s API。用户和k8s service account都可以被授权访问API。当请求到达API时，他会经过多个阶段，如下图所示

Controlling Access to the Kubernetes API - 图1

Transport security传输安全

In a typical Kubernetes cluster, the API serves on port 443, protected by TLS. The API server presents a certificate. This certificate may be signed using a private certificate authority (CA), or based on a public key infrastructure linked to a generally recognized CA.

在一个典型的k8s集群中，API服务器在443端口服务，并受TLS保护。API服务器初始整数。该整数可以使用私有证书颁发机构(CA)签名，也可以基于链接到工人的CA公钥基础架构签名。

If your cluster uses a private certificate authority, you need a copy of that CA certificate configured into your ~/.kube/config on the client, so that you can trust the connection and be confident it was not intercepted.

Your client can present a TLS client certificate at this stage.

如果你的集群使用私有证书颁发机构，你需要在客户端的 ~/.kube/config 文件中提供该 CA 证书的副本， 以便你可以信任该连接并确认该连接没有被拦截。

你的客户端可以在此阶段出示 TLS 客户端证书

Authentication认证

Once TLS is established, the HTTP request moves to the Authentication step. This is shown as step 1 in the diagram. The cluster creation script or cluster admin configures the API server to run one or more Authenticator modules. Authenticators are described in more detail in Authentication.

TLS连接建立后，HTTP会进入认证步骤。集群创建脚本或集群管理员配置API服务器运行一个或多个认证模型，认证步骤在Authentication章节有详细描述。

The input to the authentication step is the entire HTTP request; however, it typically examines the headers and/or client certificate.

认证步骤的输入是完整的HTTP请求；然而只会检测标头和客户端证书。

Authentication modules include client certificates, password, and plain tokens, bootstrap tokens, and JSON Web Tokens (used for service accounts).

认证模块包括客户端证书、密码、普通令牌、引导令牌，JWT（用于服务账户）

Multiple authentication modules can be specified, in which case each one is tried in sequence, until one of them succeeds.

可以定义多个认证模块，在此情况下会按顺序进行尝试直到其中一个成功。

If the request cannot be authenticated, it is rejected with HTTP status code 401. Otherwise, the user is authenticated as a specific username, and the user name is available to subsequent steps to use in their decisions. Some authenticators also provide the group memberships of the user, while other authenticators do not.

如果请求无法被认证，服务器将以HTTP状态码401拒绝该请求。反之，该用户被认证为特定的username，并且该用户名可以在后续步骤中继续使用以做出决策。部分认证器还提供用户的组成员身份，其他则不提供

While Kubernetes uses usernames for access control decisions and in request logging, it does not have a User object nor does it store usernames or other information about users in its API.

尽管k8s使用用户名来进行访问控制和请求日志，它本身并没有User对象或在API中存储用户名以及用户相关信息。

Authorization

After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step 2 in the diagram.

A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.

For example, if Bob has the policy below, then he can read pods only in the namespace projectCaribou:

  1. {
  2.     "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  3.     "kind": "Policy",
  4.     "spec": {
  5.         "user": "bob",
  6.         "namespace": "projectCaribou",
  7.         "resource": "pods",
  8.         "readonly": true
  9.     }
  10. }

If Bob makes the following request, the request is authorized because he is allowed to read objects in the projectCaribou namespace:

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

If Bob makes a request to write (create or update) to the objects in the projectCaribou namespace, his authorization is denied. If Bob makes a request to read (get) objects in a different namespace such as projectFish, then his authorization is denied.

Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.

Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configure the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403).

To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see Authorization.

Admission control

Admission Control modules are software modules that can modify or reject requests. In addition to the attributes available to Authorization modules, Admission Control modules can access the contents of the object that is being created or modified.

Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object. Admission controllers do not act on requests that merely read objects. When multiple admission controllers are configured, they are called in order.

This is shown as step 3 in the diagram.

Unlike Authentication and Authorization modules, if any admission controller module rejects, then the request is immediately rejected.

In addition to rejecting objects, admission controllers can also set complex defaults for fields.

The available Admission Control modules are described in Admission Controllers.

Once a request passes all admission controllers, it is validated using the validation routines for the corresponding API object, and then written to the object store (shown as step 4).

API server ports and IPs

The previous discussion applies to requests sent to the secure port of the API server (the typical case). The API server can actually serve on 2 ports:

By default, the Kubernetes API server serves HTTP on 2 ports:

  1. localhost port:

    • is intended for testing and bootstrap, and for other components of the master node (scheduler, controller-manager) to talk to the API
    • no TLS
    • default is port 8080, change with --insecure-port flag.
    • default IP is localhost, change with --insecure-bind-address flag.
    • request bypasses authentication and authorization modules.
    • request handled by admission control module(s).
    • protected by need to have host access

  2. “Secure port”:

    • use whenever possible
    • uses TLS. Set cert with --tls-cert-file and key with --tls-private-key-file flag.
    • default is port 6443, change with --secure-port flag.
    • default IP is first non-localhost network interface, change with --bind-address flag.
    • request handled by authentication and authorization modules.
    • request handled by admission control module(s).
    • authentication and authorization modules run.

What’s next

Read more documentation on authentication, authorization and API access control:

You can learn about:

  • how Pods can use Secrets to obtain API credentials.