Understanding and creating service accounts

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.

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>

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:

    1. $ oc policy add-role-to-user view system:serviceaccount:top-secret:robot

    You can alternatively apply the following YAML to add the role:

    1. apiVersion: rbac.authorization.k8s.io/v1
    2. kind: RoleBinding
    3. metadata:
    4.   name: view
    5.   namespace: top-secret
    6. roleRef:
    7.   apiGroup: rbac.authorization.k8s.io
    8.   kind: ClusterRole
    9.   name: view
    10. subjects:
    11. - kind: ServiceAccount
    12.   name: robot
    13.   namespace: top-secret

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

    1. $ oc policy add-role-to-user <role_name> -z <service_account_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.

    You can alternatively apply the following YAML to add the role:

    1. apiVersion: rbac.authorization.k8s.io/v1
    2. kind: RoleBinding
    3. metadata:
    4.   name: <rolebinding_name>
    5.   namespace: <current_project_name>
    6. roleRef:
    7.   apiGroup: rbac.authorization.k8s.io
    8.   kind: ClusterRole
    9.   name: <role_name>
    10. subjects:
    11. - kind: ServiceAccount
    12.   name: <service_account_name>
    13.   namespace: <current_project_name>

  • 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 my-project project:

      1. $ oc policy add-role-to-group view system:serviceaccounts -n my-project

      You can alternatively apply the following YAML to add the role:

      1. apiVersion: rbac.authorization.k8s.io/v1
      2. kind: RoleBinding
      3. metadata:
      4.   name: view
      5.   namespace: my-project
      6. roleRef:
      7.   apiGroup: rbac.authorization.k8s.io
      8.   kind: ClusterRole
      9.   name: view
      10. subjects:
      11. - apiGroup: rbac.authorization.k8s.io
      12.   kind: Group
      13.   name: system:serviceaccounts

    • To allow all service accounts in the managers project to edit resources in the my-project project:

      1. $ oc policy add-role-to-group edit system:serviceaccounts:managers -n my-project

      You can alternatively apply the following YAML to add the role:

      1. apiVersion: rbac.authorization.k8s.io/v1
      2. kind: RoleBinding
      3. metadata:
      4.   name: edit
      5.   namespace: my-project
      6. roleRef:
      7.   apiGroup: rbac.authorization.k8s.io
      8.   kind: ClusterRole
      9.   name: edit
      10. subjects:
      11. - apiGroup: rbac.authorization.k8s.io
      12.   kind: Group
      13.   name: system:serviceaccounts:managers