---
title: Understanding and creating service accounts
---

# Understanding and creating service accounts {#understanding-and-creating-service-accounts}

To control API access without sharing regular user credentials, you can use service accounts.

## Service accounts overview {#service-accounts-overview_understanding-service-accounts}

You can use OpenShift Container Platform service accounts to allow a OpenShift Container Platform component to directly access the API.

Service accounts are API objects that exist within each project that provide a flexible way to control API access without sharing a regular user’s credentials.

When you use the OpenShift Container Platform 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:

```text
system:serviceaccount:<project>:<name>
```

Every service account is also a member of two groups:

| Group | Description |
| --- | --- |
| system:serviceaccounts | Includes all service accounts in the system. |
| system:serviceaccounts:<project> | Includes all service accounts in the specified project. |

### Automatically generated image pull secrets {#auto-generated-sa-token-secrets_understanding-service-accounts}

OpenShift Container Platform automatically creates image pull secrets for each service account to integrate the internal image registry with user authentication.

> [!NOTE]
> Prior to OpenShift Container Platform 4.16, a long-lived service account API token secret was also generated for each service account that was created. Starting with OpenShift Container Platform 4.16, this service account API token secret is no longer created.
>
> After upgrading to 4.22, any existing long-lived service account API token secrets are not deleted and will continue to function. For information about detecting long-lived API tokens that are in use in your cluster or deleting them if they are not needed, see "Long-lived service account API tokens in OpenShift Container Platform (Red Hat Knowledgebase)".

This image pull secret is necessary to integrate the OpenShift image registry into the cluster’s user authentication and authorization system.

However, if you do not enable the `ImageRegistry` capability or if you disable the integrated OpenShift image registry in the Cluster Image Registry Operator’s configuration, an image pull secret is not generated for each service account.

When the integrated OpenShift image registry is disabled on a cluster that previously had it enabled, the previously generated image pull secrets are deleted automatically.

## Creating service accounts {#service-accounts-managing_understanding-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:

   ```terminal
   $ oc get sa
   ```

   ```terminal {title="Example output"}
   NAME       SECRETS   AGE
   builder    1         2d
   default    1         2d
   deployer   1         2d
   ```
2. To create a new service account in the current project:

   ```terminal
   $ oc create sa <service_account_name>
   ```

   To create a service account in a different project, specify `-n <project_name>`.

   ```terminal {title="Example output"}
   serviceaccount "robot" created
   ```

   > [!TIP]
   > You can alternatively apply the following YAML to create the service account:
   >
   > ```yaml
   > apiVersion: v1
   > kind: ServiceAccount
   > metadata:
   >   name: <service_account_name>
   >   namespace: <current_project>
   > ```
3. Optional: View the secrets for the service account:

   ```terminal
   $ oc describe sa robot
   ```

   ```terminal {title="Example output"}
   Name:                robot
   Namespace:           project1
   Labels:              <none>
   Annotations:         openshift.io/internal-registry-pull-secret-ref: robot-dockercfg-qzbhb
   Image pull secrets:  robot-dockercfg-qzbhb
   Mountable secrets:   robot-dockercfg-qzbhb
   Tokens:              <none>
   Events:              <none>
   ```

## Granting roles to service accounts {#service-accounts-granting-roles_understanding-service-accounts}

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

**Procedure**

1. 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:

   ```terminal
   $ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
   ```

   > [!TIP]
   > You can alternatively apply the following YAML to add the role:
   >
   > ```yaml
   > apiVersion: rbac.authorization.k8s.io/v1
   > kind: RoleBinding
   > metadata:
   >   name: view
   >   namespace: top-secret
   > roleRef:
   >   apiGroup: rbac.authorization.k8s.io
   >   kind: ClusterRole
   >   name: view
   > subjects:
   > - kind: ServiceAccount
   >   name: robot
   >   namespace: top-secret
   > ```
2. 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>`

   ```terminal
   $ oc policy add-role-to-user <role_name> -z <service_account_name>
   ```

   > [!IMPORTANT]
   > 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.

   > [!TIP]
   > You can alternatively apply the following YAML to add the role:
   >
   > ```yaml
   > apiVersion: rbac.authorization.k8s.io/v1
   > kind: RoleBinding
   > metadata:
   >   name: <rolebinding_name>
   >   namespace: <current_project_name>
   > roleRef:
   >   apiGroup: rbac.authorization.k8s.io
   >   kind: ClusterRole
   >   name: <role_name>
   > subjects:
   > - kind: ServiceAccount
   >   name: <service_account_name>
   >   namespace: <current_project_name>
   > ```
3. 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:

     ```terminal
     $ oc policy add-role-to-group view system:serviceaccounts -n my-project
     ```

     > [!TIP]
     > You can alternatively apply the following YAML to add the role:
     >
     > ```yaml
     > apiVersion: rbac.authorization.k8s.io/v1
     > kind: RoleBinding
     > metadata:
     >   name: view
     >   namespace: my-project
     > roleRef:
     >   apiGroup: rbac.authorization.k8s.io
     >   kind: ClusterRole
     >   name: view
     > subjects:
     > - apiGroup: rbac.authorization.k8s.io
     >   kind: Group
     >   name: system:serviceaccounts
     > ```
   - To allow all service accounts in the `managers` project to edit resources in the `my-project` project:

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

     > [!TIP]
     > You can alternatively apply the following YAML to add the role:
     >
     > ```yaml
     > apiVersion: rbac.authorization.k8s.io/v1
     > kind: RoleBinding
     > metadata:
     >   name: edit
     >   namespace: my-project
     > roleRef:
     >   apiGroup: rbac.authorization.k8s.io
     >   kind: ClusterRole
     >   name: edit
     > subjects:
     > - apiGroup: rbac.authorization.k8s.io
     >   kind: Group
     >   name: system:serviceaccounts:managers
     > ```