Table of Contents

• Service accounts
  • Default service accounts
  • Manage Service Accounts
• Security Context Constraints

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:

system:serviceaccount:<project>:<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

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

Several infrastructure controllers run using service account credentials. The following service accounts are created in the OKD infrastructure project (openshift-infra) at server start, and given the following roles cluster-wide:

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.

https://docs.okd.io/latest/authentication/understanding-and-creating-service-accounts.html https://docs.okd.io/latest/authentication/using-service-accounts-in-applications.html

oc get sa

oc create sa <service_account_name>

oc describe sa/<service_account_name>

oc adm policy add-role-to-user <role> system.serviceaccount.<project>.<service_account_name>

Similar to the way that RBAC resources control user access, administrators can use Security Context Constraints (SCCs) to control permissions for pods. These permissions include actions that a pod, a collection of containers, can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with in order to be accepted into the system.

SCCs allow an administrator to control:

• Whether a pod can run privileged containers.
• The capabilities that a container can request.
• The use of host directories as volumes.
• The SELinux context of the container.
• The container user ID.
• The use of host namespaces and networking.
• The allocation of an FSGroup that owns the pod’s volumes.
• The configuration of allowable supplemental groups.
• Whether a container requires the use of a read only root file system.
• The usage of volume types.
• The configuration of allowable seccomp profiles.

https://docs.okd.io/latest/authentication/managing-security-context-constraints.html