Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 8. Understanding and creating service accounts


8.1. 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.

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:

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.

8.2. 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

    Example output

    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
    1
    To create a service account in a different project, specify -n <project_name>.

    Example output

    serviceaccount "robot" created

    Tip

    You can alternatively apply the following YAML to create the service account:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: <service_account_name>
      namespace: <current_project>
  3. Optional: View the secrets for the service account:

    $ oc describe sa robot

    Example output

    Name:                robot
    Namespace:           project1
    Labels:	             <none>
    Annotations:	     <none>
    Image pull secrets:  robot-dockercfg-qzbhb
    Mountable secrets:   robot-dockercfg-qzbhb
    Tokens:              robot-token-f4khf
    Events:              <none>

8.3. 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
    Tip

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

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

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

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

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

      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:

      $ 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:

      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
Red Hat logoGithubRedditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

© 2024 Red Hat, Inc.