Using service accounts in applications

When you use the OKD CLI or web console, your API token authenticates you to the API. You can associate a component with a service account so that they can access the API without using a regular user’s credentials. For example, service accounts can allow:

Replication controllers to make API calls to create or delete pods.
Applications inside containers to make API calls for discovery purposes.
External applications to make API calls for monitoring or integration purposes.

Each service account’s user name is derived from its project and name:

Every service account is also a member of two groups:

Each service account automatically contains two secrets:

Credentials for the OpenShift Container Registry

The generated API token and registry credentials do not expire, but you can revoke them by deleting the secret. When you delete the secret, a new one is automatically generated to take its place.

Several infrastructure controllers run using service account credentials. The following service accounts are created in the OKD infrastructure project () at server start, and given the following roles cluster-wide:

Service Account	Description
`replication-controller`	Assigned the `system:replication-controller` role
`deployment-controller`	Assigned the `system:deployment-controller` role
`build-controller`	Assigned the `system:build-controller` role. Additionally, the `build-controller` service account is included in the privileged security context constraint to create privileged build pods.

Three service accounts are automatically created in each project:

In 4.13, OKD is adopting an , which enables the LegacyServiceAccountTokenNoAutoGeneration feature by default. As a result, when creating new service accounts (SA), a service account token secret is no longer automatically generated. Previously, OKD automatically added a service account token to a secret for each new SA.

However, some features and workloads need service account token secrets to communicate with the Kubernetes API server, for example, the OpenShift Controller Manager. While this requirement will be changed in a future release, it remains in OKD 4.13. As a result, if you need a service account token secret, you must manually use the TokenRequest API to request bound service account tokens or create a service account token secret.

After upgrading to 4.13, existing service account token secrets are not deleted and continue to function as expected.

In 4.13, service account token secrets are still automatically generated. Instead of creating two secrets per service account, OKD now only creates one. In a future release, the number will be further reduced to zero. Note that dockercfg secrets are still generated and no secrets are deleted during upgrades.

Additional resources

For information about requesting bound service account tokens, see Configuring bound service account tokens using volume projection
For information about creating a service account token secret, see .

You can create a service account in a project and grant it permissions by binding it to a role.

Procedure

Optional: To view the service accounts in the current project:
```
$ oc get sa
```
Example output
To create a new service account in the current project:
```
$ oc create sa <service_account_name> (1)
```
Example output
You can alternatively apply the following YAML to create the service account:
apiVersion: v1
name: <service_account_name>
namespace: <current_project>

Example output

Name:                robot
Namespace:           project1
Labels:                 <none>
Annotations:         <none>
Image pull secrets:  robot-dockercfg-qzbhb
Mountable secrets:   robot-dockercfg-qzbhb
Events:              <none>