Users in Kubernetes

All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users.

It is assumed that a cluster-independent service manages normal users in the following ways:

an administrator distributing private keys

a user store like Keystone or Google Accounts

a file with a list of usernames and passwords

In this regard, Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call.

在这方面，Kubernetes没有代表普通用户帐户的对象。 无法通过API调用将普通用户添加到群集中。

Even though a normal user cannot be added via an API call, any user that presents a valid certificate signed by the cluster's certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the 'subject' of the cert (e.g., "/CN=bob"). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. For more details, refer to the normal users topic in certificate request for more details about this.

即使无法通过API调用添加普通用户，任何提供了由群集的证书颁发机构（CA）签名的有效证书的用户都被视为已通过身份验证。 在这种配置中，Kubernetes从证书的``主题''中的通用名称字段中确定用户名（例如，``/ CN = bob''）。 从那里，基于角色的访问控制（RBAC）子系统将确定用户是否被授权对资源执行特定操作。 有关更多详细信息，请参阅证书申请中的“普通用户”主题以获取有关此信息的更多详细信息。

In contrast, service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials stored as Secrets, which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API.

API requests are tied to either a normal user or a service account, or are treated as anonymous requests. This means every process inside or outside the cluster, from a human user typing kubectl on a workstation, to kubelets on nodes, to members of the control plane, must authenticate when making requests to the API server, or be treated as an anonymous user.

Authentication strategies

Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins. As HTTP requests are made to the API server, plugins attempt to associate the following attributes with the request:

Username: a string which identifies the end user. Common values might be kube-admin or jane@example.com.

UID: a string which identifies the end user and attempts to be more consistent and unique than username.

Groups: a set of strings, each of which indicates the user's membership in a named logical collection of users. Common values might be system:masters or devops-team.

Extra fields: a map of strings to list of strings which holds additional information authorizers may find useful.

All values are opaque to the authentication system and only hold significance when interpreted by an authorizer.

用户名：标识最终用户的字符串。 常见值可能是kube-admin或jane@example.com。

UID：一个字符串，用于标识最终用户，并尝试使其比用户名更加一致和唯一。

组：一组字符串，每个字符串指示用户在命名的用户逻辑集合中的成员身份。 常见的值可能是system：masters或devops-team。

额外字段：字符串到字符串列表的映射，其中包含授权者的其他信息可能会有用。

所有值对于身份验证系统都是不透明的，并且仅在授权者解释时才有意义。

You can enable multiple authentication methods at once. You should usually use at least two methods:

service account tokens for service accounts

at least one other method for user authentication.

When multiple authenticator modules are enabled, the first module to successfully authenticate the request short-circuits evaluation. The API server does not guarantee the order authenticators run in.

The system:authenticated group is included in the list of groups for all authenticated users.

系统：已认证的组包含在所有已认证用户的组列表中。

Integrations with other authentication protocols (LDAP, SAML, Kerberos, alternate x509 schemes, etc) can be accomplished using an authenticating proxy or the authentication webhook.

X509 Client Certs

Client certificate authentication is enabled by passing the --client-ca-file=SOMEFILE option to API server. The referenced file must contain one or more certificate authorities to use to validate client certificates presented to the API server. If a client certificate is presented and verified, the common name of the subject is used as the user name for the request. As of Kubernetes 1.4, client certificates can also indicate a user's group memberships using the certificate's organization fields. To include multiple group memberships for a user, include multiple organization fields in the certificate.

从Kubernetes 1.4开始，客户端证书还可以使用证书的组织字段指示用户的组成员身份。 要为用户包括多个组成员身份，请在证书中包括多个组织字段。

For example, using the openssl command line tool to generate a certificate signing request:

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2".

See Managing Certificates for how to generate a client cert.

Static Token File

The API server reads bearer tokens from a file when given the --token-auth-file=SOMEFILE option on the command line. Currently, tokens last indefinitely, and the token list cannot be changed without restarting API server.

The token file is a csv file with a minimum of 3 columns: token, user name, user uid, followed by optional group names.

Note:

If you have more than one group the column must be double quoted e.g.

token,user,uid,"group1,group2,group3"

Putting a Bearer Token in a Request

When using bearer token authentication from an http client, the API server expects an Authorization header with a value of Bearer THETOKEN. The bearer token must be a character sequence that can be put in an HTTP header value using no more than the encoding and quoting facilities of HTTP. For example: if the bearer token is 31ada4fd-adec-460c-809a-9e56ceb75269 then it would appear in an HTTP header as shown below.

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

Bootstrap Tokens

FEATURE STATE: Kubernetes v1.18 [stable]

To allow for streamlined bootstrapping for new clusters, Kubernetes includes a dynamically-managed Bearer token type called a Bootstrap Token. These tokens are stored as Secrets in the kube-system namespace, where they can be dynamically managed and created. Controller Manager contains a TokenCleaner controller that deletes bootstrap tokens as they expire.

The tokens are of the form [a-z0-9]{6}.[a-z0-9]{16}. The first component is a Token ID and the second component is the Token Secret. You specify the token in an HTTP header as follows:

Authorization: Bearer 781292.db7bc3a58fc5f07e

You must enable the Bootstrap Token Authenticator with the --enable-bootstrap-token-auth flag on the API Server. You must enable the TokenCleaner controller via the --controllers flag on the Controller Manager. This is done with something like --controllers=*,tokencleaner. kubeadm will do this for you if you are using it to bootstrap a cluster.

The authenticator authenticates as system:bootstrap:<Token ID>. It is included in the system:bootstrappers group. The naming and groups are intentionally limited to discourage users from using these tokens past bootstrapping. The user names and group can be used (and are used by kubeadm) to craft the appropriate authorization policies to support bootstrapping a cluster.

Please see Bootstrap Tokens for in depth documentation on the Bootstrap Token authenticator and controllers along with how to manage these tokens with kubeadm.

Service Account Tokens

A service account is an automatically enabled authenticator that uses signed bearer tokens to verify requests. The plugin takes two optional flags:

--service-account-key-file A file containing a PEM encoded key for signing bearer tokens. If unspecified, the API server's TLS private key will be used.

--service-account-lookup If enabled, tokens which are deleted from the API will be revoked.

Service accounts are usually created automatically by the API server and associated with pods running in the cluster through the ServiceAccount Admission Controller. Bearer tokens are mounted into pods at well-known locations, and allow in-cluster processes to talk to the API server. Accounts may be explicitly associated with pods using the serviceAccountName field of a PodSpec.

Note: serviceAccountName is usually omitted because this is done automatically.

apiVersion: apps/v1 # this apiVersion is relevant as of Kubernetes 1.9

kind: Deployment

metadata:

  name: nginx-deployment

  namespace: default

spec:

  replicas: 3

  template:

    metadata:

    # ...

    spec:

      serviceAccountName: bob-the-bot

      containers:

      - name: nginx

        image: nginx:1.14.2

Service account bearer tokens are perfectly valid to use outside the cluster and

can be used to create identities for long standing jobs that wish to talk to the Kubernetes API. To manually create a service account, simply use the kubectl

create serviceaccount (NAME)` command. This creates a service account in the current namespace and an associated secret.

kubectl create serviceaccount jenkins

serviceaccount "jenkins" created

Check an associated secret:

kubectl get serviceaccounts jenkins -o yaml

apiVersion: v1

kind: ServiceAccount

metadata:

  # ...

secrets:

- name: jenkins-token-1yvwg

The created secret holds the public CA of the API server and a signed JSON Web Token (JWT).

kubectl get secret jenkins-token-1yvwg -o yaml

apiVersion: v1

data:

  ca.crt: (APISERVER'S CA BASE64 ENCODED)

  namespace: ZGVmYXVsdA==

  token: (BEARER TOKEN BASE64 ENCODED)

kind: Secret

metadata:

  # ...

type: kubernetes.io/service-account-token

Note: Values are base64 encoded because secrets are always base64 encoded.

The signed JWT can be used as a bearer token to authenticate as the given service account. See above for how the token is included in a request. Normally these secrets are mounted into pods for in-cluster access to the API server, but can be used from outside the cluster as well.

Service accounts authenticate with the username system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT), and are assigned to the groups system:serviceaccounts and system:serviceaccounts:(NAMESPACE).

WARNING: Because service account tokens are stored in secrets, any user with read access to those secrets can authenticate as the service account. Be cautious when granting permissions to service accounts and read capabilities for secrets