Secrets and Service Accounts on Openshift


  • A secret is a base64 encoded ConfigMap
  • To really protect data in a secret, the Etcd can be encrypted
  • Secrets are commonly used to decouple configuration and data from the applications running in OpenShift
  • Using secrets allows OpenShift to load site-specific data from external sources
  • Secrets can be used to store different kinds of data
    • Passwords
    • Sensitive configuration files
    • Credentials such as SSH keys or OAuth tokens

Secret Types

  • Different types of secrets exist:
    • docker-registry
    • generic
    • tls
  • When information is stored in a secret, OpenShift validates that the data conforms to the type of secret
  • In OpenShift, secrets are mainly used for two reasons
    • To store credentials which is used by Pods in a MicroService architecture
    • To store TLS certificates and keys
    • A TLS secret stores the certificate as tls.crt and the certificate key as tls.key
    • Developers can mount the secret as a volume and create a pass-through route to the application

Creating Secrets

  • Generic secrets: oc create secret generic secretvars --from-literal user=root --from-literal password=verysecret
  • Generic secrets, containing SSH keys: oc create secret generic ssh-keys --from-file id_rsa=nissh/id_rsa --from-file"sissh/
  • Secrets containing TLS certificate and key: oc create secret tls secret-tls -- cert certsitls.crt keysitls.key

Exposing Secrets to Pods

  • Secrets can be referred to as variables, or as files from the Pod
  • Use oc set env to write the environment variables obtained from a secret to a pod or deployment
    • oc set env deployment/mysql --from secret/mysql --prefix MYSQL_
  • Use oc set volume to mount secrets as volumes
  • Notice that when using oc set volume, all files currently in the target directory are no longer accessible
    • oc set volume deployment/mysql --add --type secret --mount-path /run/secrets/mysql --secret-name mysql
  • Notice that oc set env can use --prefix to add a prefix to the environment variables defined in the secret



  • A ServiceAccount (SA) is a user account that is used by a Pod to determine Pod access privileges to system resources
  • The default ServiceAccount used by Pods allows for very limited access to cluster resources
  • Sometimes a Pod cannot run with this very restricted ServiceAccount
  • After creating the ServiceAccount, specific access privileges need to be set

Configuring ServiceAccount Access Restrictions

  • To create a ServiceAccount, use oc create serviceaccount mysa
  • Optionally, add -n namespace to assign the SA to a specific namespace
  • After creating the SA, use a role binding to connect the SA to a specific role
  • Or associate the SA with a specific Security Context Constraint



Security Context Constraints

  • A Security Context Constraint (SCC) is an OpenShift resource, similar to the Kubernetes Security Context resource, that restricts access to resources
  • The purpose is to limit access from a Pod to the host environment
  • Different SCCs are available to control:
    • Running privileged containers
    • Requesting additional capabilities to a container
    • Using host directories as volumes
    • Changing SELinux context of a container
    • Changing the user ID
  • Using SCCs may be necessary to run community containers that by default don’t work under the tight OpenShift security restrictions

Exploring SCCs

  • Use oc get scc for an overview of SCCs
  • For more details, use oc describe scc <name>, as in oc describe scc nonroot
  • Use oc describe pod <podname> | grep scc to see which SCC is currently used by a Pod
  • If a Pod can’t run due to an SCC, use oc get pod <name> -o yaml | oc adm policy scc-subject-review -f -
  • To change a container to run with a different SCC, you must create a service account and use that in the Pod


Using SCCs

  • oc get scc gives an overview of all SCCs
  • oc describe scc anyuid shows information about a specific SCC
  • oc describe pod shows a line restricted; most Pods run as restricted
  • Some Pods require access beyond the scope of their own containers, such as S21 Pods. To provide this access, SAs are needed
  • To change the container to run using a different SCC, you need to create a service account and use that with the Pod or Deployment


Understanding SCC and ServiceAccount

  • The service account is used to connect to an SCC
  • Once the service account is connected to the SCC it can be bound to a deployment or pod to make sure that it is working
  • This allows you for instance to run a Pod that requires root access to use the anyuid SCC so that it can run anyway

Demo: using SCCs

  • As developer: oc new-project sccs
  • oc new-app --name sccnginx --docker-image nginx
  • oc get pods will show an error
  • oc logs pod/nginx[Tab] will show that is fails because of a permission problem
  • as admin: oc get pod nginx[Tab] -o yaml | oc adm policy scc-subject-review -f - will show which scc to use
  • as admin: oc create sa nginx-sa creates the dedicated service account
  • As administrator: oc adm policy add-scc-to-user anyuid -z nginx-sa
  • As developer: oc set serviceaccount deployment sccnginx nginx-sa
  • oc get pods sccs[Tab] -o yaml; look for serviceAccount
  • oc get pods should show the pod as running (may have to wait a minute)


Running Containers as Non-root

  • By default, OpenShift denies containers to run as root
  • Many containers run as root by default
  • A container that runs as root has root privileges on the container host as well, and should be avoided
  • If you build your own container images, specify which user it should run
  • Frequently, non-root alternatives are available for the images you’re using
    • images are made with OpenShift in mind
    • bitnami has reworked common images to be started as non-root:

Managing Non-root Container Ports

  • Non-root containers cannot bind to a privileged port
  • In OpenShift, this is not an issue, as containers are accessed through services and routes
  • Configure the port on the service/route, not on the Pod
  • Also, non-root containers will have limitations accessing files

Running Bitnami non-root Nginx

  • oc new-app --docker-image bitnami/nginx:latest --name=bginx
  • oc get pods -o wide
  • oc describe pods bginx-<xxx>
  • oc get services