Using service accounts in applications

    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:

    Every service account is also a member of two groups:

    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.

    Your OKD cluster contains default service accounts for cluster management and generates more service accounts for each project.

    Default project service accounts and roles

    Three service accounts are automatically created in each project:

    All service accounts in a project are given the system:image-puller role, which allows pulling images from any imagestream in the project using the internal container image registry.

    You can create a service account in a project and grant it permissions by binding it to a role.

    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

    2. 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>
      6. Image pull secrets:    robot-dockercfg-qzbhb
      8. Mountable secrets:     robot-token-f4khf
      9.                        robot-dockercfg-qzbhb
      11. Tokens:                robot-token-f4khf
      12.                        robot-token-z8h44

    You can distribute a service account’s token to external applications that must authenticate to the API.

    To pull an image, the authenticated user must have get rights on the requested imagestreams/layers. To push an image, the authenticated user must have rights on the requested imagestreams/layers.

    By default, all service accounts in a project have rights to pull any image in the same project, and the builder service account has rights to push any image in the same project.

    Procedure

    1. View the service account’s API token:

      1. $ oc describe secret <secret_name>

      For example:

      Example output

      1. Labels:        <none>
      2. Annotations:    kubernetes.io/service-account.name=robot,kubernetes.io/service-account.uid=49f19e2e-16c6-11e5-afdc-3c970e4b7ffe
      4. Type:    kubernetes.io/service-account-token
      6. Data
      8. token:    eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

    2. Log in using the token that you obtained:

      1. $ oc login --token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

      Example output

      1. Logged into "https://server:8443" as "system:serviceaccount:top-secret:robot" using the token provided.
      3. You don't have any projects. You can try to create a new project, by running
      5.     $ oc new-project <projectname>

    3. Example output