Inside of Kubernetes component: API Server — Authentication

We start with the API server what it contains, secondly we go with what all Authentication Kubernetes supports.

To authenticate with the API server, you used the ServiceAccount token mounted into the pod. This certificate is often self-signed, so $USER/.kube/config on the user’s machine typically contains the root certificate for the API server’s certificate, which when specified is used in place of the system default root certificate.

Diagram depicts the flow of API server.

1. Authentication: Authentication modules include Client Certificates, Password, and Plain Tokens, Bootstrap Tokens, and JWT Tokens (used for service accounts).I f 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.

2. Authorization: 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 configured 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.

3. Admission Control: Admission Control Modules are software modules that can modify or reject requests. Authorization Modules, Admission Control Modules can access the contents of the object that is being created or updated. They act on objects being created, deleted, updated or connected (proxy), but not reads. 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.

Overview of Authentication:

a. Users:

There are two types of Users: service accounts managed by Kubernetes, and normal users.

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

Service Accounts users: 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.

b. Authentication strategies

Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins.

1. 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. Used by the kubernetes 1.4
2. 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 the 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. When using bearer token authentication from an http client, the API server expects an Authorization header with a value of Bearer THETOKEN.
3. Bootstrap Tokens: Kubernetes (v1.18) 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.
4. Static File Password: Basic authentication is enabled by passing the — basic-auth-file=SOMEFILE option to API server. Currently, the basic auth credentials last indefinitely, and the password cannot be changed without restarting API server. The basic auth file is a csv file with a minimum of 3 columns: password, user name, user id. When using basic authentication from an http client, the API server expects an Authorization header with a value of Basic BASE64ENCODED(USER:PASSWORD) .
5. Service Accounts: Service accounts are usually created automatically by the API server and associated with pods running in the cluster through the ServiceAccount Admission Control. 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.
6. OpenID Connect Tokens: It is a flavor of OAuth2 supported by some OAuth2 providers, notably Azure Active Directory, Salesforce, and Google. The protocol’s main extension of OAuth2 is an additional field returned with the access token called an ID Token.This token is a JSON Web Token (JWT) with well known fields, such as a user’s email, signed by the server. To identify the user, the authenticator uses the id_token (not the access_token) from the OAuth2 token request as a bearer token.
7. Webhook Token Authentication: Webhook authentication is a hook for verifying bearer tokens. — authentication-token-webhook-config-file a configuration file describing how to access the remote webhook service and — authentication-token-webhook-cache-ttl how long to cache authentication decisions. Defaults to two minutes. When a client attempts to authenticate with the API server using a bearer token, the authentication webhook POSTs a JSON-serialized authentication.k8s.io/v1beta1 TokenReview object containing the token to the remote service. Kubernetes will not challenge a request that lacks such a header.
8. Authenticating Proxy: The API server can be configured to identify users from request header values, such as X-Remote-User. It is designed for use in combination with an authenticating proxy, which sets the request header value. — requestheader-username-headers Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the username. — requestheader-group-headers 1.6+. Optional, case-insensitive. “X-Remote-Group” is suggested. Header names to check, in order, for the user’s groups. All values in all specified headers are used as group names. — requestheader-extra-headers-prefix 1.6+. Optional, case-insensitive. “X-Remote-Extra-” is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed.