Overview

When a person uses the OpenShift Container Platform CLI or web console, their API token
authenticates them to the OpenShift API. However, when a regular user’s
credentials are not available, it is common for components to make API calls
independently.
For example:

Replication controllers make API calls to create or delete pods.

Applications inside containers could make API calls for discovery purposes.

External applications could make API calls for monitoring or integration purposes.

Service accounts provide a flexible way to control API access without sharing a
regular user’s credentials.

User Names and Groups

Every service account has an associated user name that can be granted roles,
just like a regular user. The user name is derived from its project and name:

system:serviceaccount:<project>:<name>

For example, to add the view role to the robot service account in the
top-secret project:

If you want to grant access to a specific service account in a project, you can
use the -z flag. From the project to which the service account belongs, use
the -z flag and specify the <serviceaccount_name>. This is highly
recommended, as it helps prevent typos and ensures that access is granted only
to the specified service account. For example:

$ oc policy add-role-to-user <role_name> -z <serviceaccount_name>

If not in the project, use the -n option to indicate the project namespace it
applies to, as shown in the examples below.

Every service account is also a member of two groups:

system:serviceaccount

Includes all service accounts in the system.

system:serviceaccount:<project>

Includes all service accounts in the
specified project.

For example, to allow all service accounts in all projects to view resources in
the top-secret project:

The system ensures that service accounts always have an API token and registry
credentials.

The generated API token and registry credentials do not expire, but they can be
revoked by deleting the secret. When the secret is deleted, a new one is
automatically generated to take its place.

Managing Allowed Secrets

In addition to providing API credentials, a pod’s service account determines
which secrets the pod is allowed to use.

Pods use secrets in two ways:

image pull secrets, providing credentials used to pull images for the pod’s containers

mountable secrets, injecting the contents of secrets into containers as files

To allow a secret to be used as an image pull secret by a service account’s
pods, run:

$ oc secrets link --for=pull <serviceaccount-name> <secret-name>

To allow a secret to be mounted by a service account’s pods, run:

$ oc secrets link --for=mount <serviceaccount-name> <secret-name>

Limiting secrets to only the service accounts that reference them is disabled by
default. This means that if serviceAccountConfig.limitSecretReferences is set
to false (the default setting) in the master configuration file, mounting
secrets to a service account’s pods with the --for=mount option is not
required. However, using the --for=pull option to enable using an image pull
secret is required, regardless of the
serviceAccountConfig.limitSecretReferences value.