This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.Questo contenuto non è disponibile nella lingua selezionata.
Chapter 10. Understanding and creating service accounts
10.1. Service accounts overview Copia collegamentoCollegamento copiato negli appunti!
A service account is an OpenShift Container Platform 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 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:
system:serviceaccount:<project>:<name>
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. |
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.
10.2. Creating service accounts Copia collegamentoCollegamento copiato negli appunti!
You can create a service account in a project and grant it permissions by binding it to a role.
Procedure
Optional: To view the service accounts in the current project:
oc get sa
$ oc get sa
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME SECRETS AGE builder 2 2d default 2 2d deployer 2 2d
NAME SECRETS AGE builder 2 2d default 2 2d deployer 2 2d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To create a new service account in the current project:
oc create sa <service_account_name>
$ oc create sa <service_account_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- To create a service account in a different project, specify
-n <project_name>
.
Example output
serviceaccount "robot" created
serviceaccount "robot" created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: View the secrets for the service account:
oc describe sa robot
$ oc describe sa robot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3. Examples of granting roles to service accounts Copia collegamentoCollegamento copiato negli appunti!
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 therobot
service account in thetop-secret
project:oc policy add-role-to-user view system:serviceaccount:top-secret:robot
$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
oc policy add-role-to-user <role_name> -z <service_account_name>
$ oc policy add-role-to-user <role_name> -z <service_account_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantIf 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
$ oc policy add-role-to-group view system:serviceaccounts -n top-secret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To allow all service accounts in the
managers
project to edit resources in thetop-secret
project:oc policy add-role-to-group edit system:serviceaccounts:managers -n top-secret
$ oc policy add-role-to-group edit system:serviceaccounts:managers -n top-secret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow