Service accounts overview

A service account is an OpenShift Dedicated 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 OpenShift Dedicated 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:

system:serviceaccount:<project>:<name>

Every service account is also a member of two groups:

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.

Service accounts in OpenShift Dedicated

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, which grants OpenShift Dedicated administrator access to all service accounts within the dedicated-admin project. You can then use these service accounts to perform any actions that require OpenShift Dedicated administrator access.

Users that are members of the dedicated-admins group are granted the dedicated-admin role permissions and have edit access to the dedicated-admin project. These users can 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.

About the dedicated administrator role

The accounts for dedicated administrators of an OpenShift Dedicated cluster, have increased permissions and access to all user-created projects.

When your account has the dedicated-admins-cluster authorization role bound to it, you are automatically bound to the dedicated-admins-project role for any new projects that users in the cluster create.

You can perform actions that are associated with a set of verbs, such as create, to operate on a set of resource names, such as templates. To view the details of these roles and their sets of verbs and resources, run the following commands:

$ oc describe clusterrole/dedicated-admins-cluster
$ oc describe clusterrole/dedicated-admins-project

The verb names do not necessarily all map directly to oc commands but rather equate more generally to the types of CLI operations you can perform. For example, having the list verb means that you can display a list of all objects of a given resource name by running the oc get command, but the get verb means that you can display the details of a specific object if you know its name by runnign the oc describe command.

OpenShift Dedicated administrators can grant users a dedicated-reader role, which provides view-only access at the cluster level and view access for all user projects.

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:

    $ oc get sa
    
    NAME       SECRETS   AGE
    builder    2         2d
    default    2         2d
    deployer   2         2d
  2. To create a new service account in the current project:

    $ oc create sa <service_account_name> (1)
    
    serviceaccount "robot" created
    1 To create a service account in a different project, specify -n <project_name>.
  3. Optional: View the secrets for 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

Examples of granting roles to service accounts

You can grant roles to service accounts in the same way that you grant roles to a regular user account.

  • You can modify the service accounts for the current project. 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
  • You can also grant access to a specific service account in a project. For example, from the project to which the service account belongs, use the -z flag and specify the <serviceaccount_name>

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

    If you want to grant access to a specific service account in a project, use the -z flag. Using this flag helps prevent typos and ensures that access is granted to only the specified service account.

  • To modify a different namespace, you can use the -n option to indicate the project namespace it applies to, as shown in the following examples.

    • 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:serviceaccounts -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:serviceaccounts:managers -n top-secret