When a person uses the OpenShift Dedicated CLI or web console, their API token authenticates them to the OpenShift Dedicated 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 can make API calls for discovery purposes.
External applications can 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.
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:
For example, to add the view role to the robot service account in the top-secret project:
$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
If you want to grant access to a specific service account in a project, you can
$ oc policy add-role-to-user <role_name> -z <serviceaccount_name>
If not in the project, use the
Every service account is also a member of two groups:
Includes all service accounts in the system.
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:
$ oc policy add-role-to-group view system:serviceaccount -n top-secret
To allow all service accounts in the managers project to edit resources in the top-secret project:
$ oc policy add-role-to-group edit system:serviceaccount:managers -n top-secret
As an OpenShift Dedicated administrator, you can use service accounts to perform any actions that require OpenShift Dedicated admin roles.
The dedicated-admin service creates the dedicated-admins group. This group is granted the roles at the cluster or individual project level. Users can be assigned to this group and group membership defines who has OpenShift Dedicated administrator access. However, by design, service accounts cannot be added to regular groups.
Instead, the dedicated-admin service creates a special project for this purpose named dedicated-admin. The service account group for this project is granted OpenShift Dedicated admin roles, granting OpenShift Dedicated administrator access to all service accounts within the dedicated-admin project. These service accounts can then be used to perform any actions that require OpenShift Dedicated administrator access.
Users that are members of the dedicated-admins group, and thus have been
granted the dedicated-admin role, have
edit access to the dedicated-admin
project. This allows these users to manage the service accounts in this project
and create new ones as needed.
Users with a dedicated-reader role are granted edit and view access to the dedicated-reader project and view-only access to the other projects.
Service accounts are API objects that exist within each project. To manage
service accounts, you can use the
oc command with the
object type or use the web console.
To get a list of existing service accounts in the current project:
$ oc get sa NAME SECRETS AGE builder 2 2d default 2 2d deployer 2 2d
To create a new service account:
$ oc create sa robot serviceaccount "robot" created
As soon as a service account is created, two secrets are automatically added to it:
an API token
credentials for the OpenShift Container Registry
These can be seen by describing the service account:
$ oc describe sa robot Name: robot Namespace: project1 Labels: <none> Annotations: <none> Image pull secrets: robot-dockercfg-qzbhb Mountable secrets: robot-token-f4khf robot-dockercfg-qzbhb Tokens: robot-token-f4khf robot-token-z8h44
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.
Service accounts authenticate to the API using tokens signed by a private RSA key. The authentication layer verifies the signature using a matching public RSA key.
To enable service account token generation, update the
stanza in the /etc/origin/master/master-config.yml file on the master to
privateKeyFile (for signing), and a matching public key file in
serviceAccountConfig: ... masterCA: ca.crt (1) privateKeyFile: serviceaccount.private.key (2) publicKeyFiles: - serviceaccount.public.key (3) - ...
|1||CA file used to validate the API server’s serving certificate.|
|2||Private RSA key file (for token signing).|
|3||Public RSA key files (for token verification). If private key files are provided, then the public key component is used. Multiple public key files can be specified, and a token will be accepted if it can be validated by one of the public keys. This allows rotation of the signing key, while still accepting tokens generated by the previous signer.|