Authentication in Kubernetes verifies the signature validity for a token or a client certificate that the user provides. Kubernetes supports any authentication method, provided that the final result of the authentication method is a token or client certificate. Because Kubernetes cannot log in by any means by itself, you need extra tools to operationalize the external authentication methods. The core components for Kubernetes authentication are the API server and the authentication plug-ins. The API server is the central control plane component that is responsible for handling incoming requests. When a request reaches the API server, it forwards the request to the appropriate authentication plug-in. The authentication plug-in validates the provided credentials and determines whether the client is authenticated.

For example, Kubernetes considers to be authenticated any user that presents a valid certificate that is signed by a trusted certificate authority (CA). Kubernetes reads the subject field from the certificate, and assigns the username and the groups with the common name (CN) and the organization (O) fields, respectively. Kubernetes either accepts or rejects the API request for the user depending on the role-based access control (RBAC) rules that are configured for the username and the group.

Kubernetes rejects any request with an invalid access token or certificate by showing a 401 Unauthorized error.

If the request does not present an access token or certificate, then Kubernetes assigns to the request the system:anonymous system user and the system:unauthenticated system group. After assigning the anonymous user to the request, Kubernetes uses RBAC policies to determine whether the anonymous user has appropriate access to perform the requested action. System groups are explained later in this section.

OpenShift expands the Kubernetes authentication mechanisms to provide additional features and integrations with external systems. OpenShift includes its own built-in OAuth server, which is not present in Kubernetes. The OpenShift OAuth server handles user authentication, and it issues OAuth tokens that grant access to specific resources.

You can authenticate to OpenShift by using the following methods:

OpenShift provides by default the authentication operator, which runs an internal OAuth server. The OAuth server issues OAuth access tokens to users for authenticating through the API. To configure authentication, the OpenShift OAuth server provides various identity providers (IdPs) that enable integration with identity management systems such as OpenID Connect and LDAP servers. Some provided IdPs support the custom OAuth workflows from internet services, such as GitHub. The OpenShift OAuth server works only with certain supported IdPs, and you cannot add other IdPs.

The most common way to authenticate to the OpenShift cluster is to use the oc login command in the command-line interface (CLI). The oc login command uses the OpenShift OAuth server to authenticate the user with an IdP. Then, the OpenShift OAuth server generates an OAuth access token for the user to authenticate their API requests.

The following diagram summarizes the authentication flow when you use the oc login command:

You can verify the two endpoints that the oc login command uses, which are the API server and the OAuth server routes, by increasing the logging level:

[user@host ~]$ oc login -u user -p password https://api.ocp4.example.com:6443 \
  --loglevel 7
I0929 ...] HEAD https://api.ocp4.example.com:6443/
I0929 ...] Request Headers:
I0929 ...] Response Status: 403 Forbidden in 20 milliseconds
I0929 ...] GSSAPI Enabled
I0929 ...] GET https://api.ocp4.example.com:6443/.well-known/oauth-authorization-server
I0929 ...] Request Headers:
I0929 ...]     X-Csrf-Token: 1
I0929 ...] Response Status: 200 OK in 0 milliseconds
I0929 ...] using system roots as no error was encountered
I0929 ...] GET https://oauth-openshift.apps.ocp4.example.com/oauth/authorize?client_id=openshift-challenging-client&code_challenge=B8RP...aCtk&code_challenge_method=S256&redirect_uri=https%3A%2F%2Foauth-openshift.apps.ocp4.example.com%2Foauth%2Ftoken%2Fimplicit&response_type=code
...output omitted...

This authentication flow is similar when using the OpenShift web console instead of the CLI, except that the OpenShift web console stores the token in the browser memory instead of in a kubeconfig file. The two endpoints for login, which are the API server and the OAuth server, are the reason why you must accept two server certificates the first time that you log in to the OpenShift web console.

After getting the OAuth access token, every time that the user invokes the OpenShift CLI, OpenShift uses the stored credentials in the kubeconfig file to authenticate the user to the Kubernetes API server. The kubeconfig file details are explained later in this course.

The following diagram summarizes the flow when you use the OpenShift CLI after authenticating by using the oc login command:

You can also retrieve OAuth user access tokens from the OpenShift OAuth server by using the <namespace_route>/oauth/authorize and <namespace_route>/oauth/token endpoints.

For an IdP to validate the identity of the requester, you must configure and enable at least one IdP in the OAuth server. If a user requests a new OAuth access token, then the OAuth server uses the configured IdPs to establish the requester's identity. After the user successfully logs in to the cluster, the OAuth server creates the OAuth access token for the user, and OpenShift creates the identity and user resources.

In production clusters, it is typical to configure multiple IdPs in the internal OAuth server. The following example shows the parameters for the custom resource (CR) to configure two IdPs in the OAuth server. The example uses htpasswd and LDAP as the IdPs.

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders: 
  - name: htpasswd-idp-name 
    mappingMethod: claim 
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpasswd-secret 
  - name: ldap-idp-name
    mappingMethod: claim
    type: LDAP
    ldap:
...output omitted...

Kubernetes does not have resources that represent user accounts, groups, or identities. Users and groups in Kubernetes are strings that Kubernetes reads from the client certificates or from the tokens.

For example, if you use a client certificate, then Kubernetes reads the common name (CN) and the organization (O) fields, and uses those strings for the username and the groups, respectively. Then, Kubernetes uses the username and groups to allow or deny the API request by using the RBAC policies.

For service accounts, which Kubernetes uses mainly to grant permissions to pods and to other resources to interact with the Kubernetes API server, Kubernetes adds only the serviceaccount string to the service account certificate or token to match RBAC policies. Service accounts are explained later in this course.

System groups or virtual groups are predefined groups that are built into the system to grant specific permissions and access rights to certain categories of users. Kubernetes creates these groups during the setup to control access to critical components and resources within the cluster. These groups are a part of cluster roles and cluster role bindings. Thus, system groups are part of the RBAC system in Kubernetes.

The following table shows some system groups in Kubernetes:

The Kubernetes API server adds the strings from system groups to the user and group strings from the client certificate or from the token, whenever they apply. Then, Kubernetes uses RBAC rules to approve or deny the request depending on the user and groups.

For example, if a user does not provide an access token or certificate, then Kubernetes assigns the system:unauthenticated group string to the request, and RBAC policies allow or deny the request depending on the RBAC rule configuration.

OpenShift includes the User resource, which defines regular users in the cluster. Regular users typically represent human users who interact with the OpenShift cluster. The OpenShift internal OAuth server automatically creates user resources when users first log in to the cluster through an IdP. You can also manually add users to the cluster by using the Kubernetes API.

OpenShift includes the Group resource, which defines groups in the cluster. Groups are logical collections of users with common access requirements. OpenShift supports users as members of one or more groups, for flexible definition of access control policies. Use groups to simplify the permissions in your cluster, to grant permissions to multiple users at the same time instead of individually. The OpenShift internal OAuth server automatically creates group resources when users first log in to the cluster through an OpenID Connect (OIDC) IdP. However, you must manually manage group resources in OpenShift for most of the supported IdPs, such as from LDAP.

OpenShift includes the Identity resource, which defines identities in the cluster. The identity resource keeps a record of successful authentication attempts from a specific user and IdP. Identities in OpenShift refer to the external identities of users. OpenShift maps user identities from IdPs to user resources. With identities, users can log in to OpenShift with their existing credentials from IdPs.