Using service accounts in applications

Service accounts overview

A service account is an OKD account that allows a component to directly access the API. Service accounts are API objects that exist within each project. Service accounts provide a flexible way to control API access without sharing a regular user’s credentials.

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:

  1. system:serviceaccount:<project>:<name>

Every service account is also a member of two groups:

GroupDescription

system:serviceaccounts

Includes all service accounts in the system.

system:serviceaccounts:<project>

Includes all service accounts in the specified project.

Each service account automatically contains two secrets:

  • An API token

  • 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.

Default service accounts

Your OKD cluster contains default service accounts for cluster management and generates more service accounts for each project.

Default cluster service accounts

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

Service AccountDescription

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.

Default project service accounts and roles

Three service accounts are automatically created in each project:

Service AccountUsage

builder

Used by build pods. It is given the system:image-builder role, which allows pushing images to any imagestream in the project using the internal Docker registry.

deployer

Used by deployment pods and given the system:deployer role, which allows viewing and modifying replication controllers and pods in the project.

default

Used to run all other pods unless they specify a different service account.

All service accounts in a project are given the system:image-puller role, which allows pulling images from any imagestream in the project using the internal container image registry.

About automatically-generated service account token secrets

In 4.12, OKD is adopting an enhancement from upstream Kubernetes, 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.12. 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.12, existing service account token secrets are not deleted and continue to function as expected.

In 4.12, service account token secrets still appear to have been automatically generated. Although, instead creating two secrets per service account, OKD now creates one token, which does not work. 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

Creating service accounts

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

Procedure

  1. Optional: To view the service accounts in the current project:

    1. $ oc get sa

    Example output

    1. NAME SECRETS AGE
    2. builder 2 2d
    3. default 2 2d
    4. deployer 2 2d
  2. To create a new service account in the current project:

    1. $ oc create sa <service_account_name> (1)
    1To create a service account in a different project, specify -n <project_name>.

    Example output

    1. serviceaccount "robot" created

    You can alternatively apply the following YAML to create the service account:

    1. apiVersion: v1
    2. kind: ServiceAccount
    3. metadata:
    4. name: <service_account_name>
    5. namespace: <current_project>
  3. Optional: View the secrets for the service account:

    1. $ oc describe sa robot

    Example output

    1. Name: robot
    2. Namespace: project1
    3. Labels: <none>
    4. Annotations: <none>
    5. Image pull secrets: robot-dockercfg-qzbhb
    6. Mountable secrets: robot-dockercfg-qzbhb
    7. Tokens: robot-token-f4khf
    8. Events: <none>