Openshift

Openshift Security Context Constraint to control permissions for pods in cluster

This section discusses Openshift Security Context Constraint that allows administrators to control permissions for pods in a cluster.

OpenShift Security Context Constraint (SCC)

Security context constraints allow administrators to control permissions for pods in a cluster. A service account provides an identity for processes that run in a pod. The default service account is used to run applications within a project. You can run other applications in the same project, but if you don't want to override the privileges used for all applications, create a new service account and grant special rights to the project where the application is run.

You can leverage all the permissions mentioned for fault execution as well as service discovery. The SCC described below is a superset, which means only some of them are required for service discovery.

Create a new service account

Note: This procedure is for automatically created service accounts. If you're using a pre-existing user-defined service account, you can skip the service account creation step and proceed directly to linking it with the Security Context Constraint.

Execute the below commands:

$ oc create serviceaccount litmus-admin

serviceaccount/litmus-admin created

Run service account as a cluster admin

Run the service account as a cluster administrator. It grants appropriate rights to the service account. This is achieved by specifying that the service account should run with a specific security context constraint (SCC).

As an administrator, you can see the list of SCCs defined in the cluster by running the oc get scc command.

$ oc get scc --as system:admin

NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]

By default, applications would run under the restricted SCC. You can use the default SCC or create your own SCC to provide the CE experiment service account (here litmus-admin) to run all the experiments. Here is one such SCC that can be used:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
# To mount the socket path directory in helper pod <a href="#to-mount-the-socket-path-directory-in-helper-pod" id="to-mount-the-socket-path-directory-in-helper-pod"></a>
allowHostDirVolumePlugin: true
allowHostIPC: false
allowHostNetwork: true
# To run fault injection on a target container using pid namespace. <a href="#to-run-fault-injection-on-a-target-container-using-pid-namespace" id="to-run-fault-injection-on-a-target-container-using-pid-namespace"></a>
# It is used in stress, network, dns and http experiments. <a href="#it-is-used-in-stress-network-dns-and-http-experiments" id="it-is-used-in-stress-network-dns-and-http-experiments"></a>
allowHostPID: true
allowHostPorts: false
allowPrivilegeEscalation: true
# To run some privileged modules in dns, stress and network chaos <a href="#to-run-some-privileged-modules-in-dns-stress-and-network-chaos" id="to-run-some-privileged-modules-in-dns-stress-and-network-chaos"></a>
allowPrivilegedContainer: true
# NET_ADMIN & SYS_ADMIN: used in network chaos experiments to perform <a href="#netadmin-and-sysadmin-used-in-network-chaos-experiments-to-perform" id="netadmin-and-sysadmin-used-in-network-chaos-experiments-to-perform"></a>
# network operations (running tc command in network ns of target container). <a href="#network-operations-running-tc-command-in-network-ns-of-target-container" id="network-operations-running-tc-command-in-network-ns-of-target-container"></a>
# SYS_ADMIN: used in stress chaos experiment to perform cgroup operations. <a href="#sysadmin-used-in-stress-chaos-experiment-to-perform-cgroup-operations" id="sysadmin-used-in-stress-chaos-experiment-to-perform-cgroup-operations"></a>
allowedCapabilities:
- 'NET_ADMIN'
- 'SYS_ADMIN'
defaultAddCapabilities: null
fsGroup:
  type: MustRunAs
groups: []
metadata:
  name: litmus-scc
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: null
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
users:
- system:serviceaccount:litmus:argo
volumes:
# To allow configmaps mounts on upload scripts or envs. <a href="#to-allow-configmaps-mounts-on-upload-scripts-or-envs" id="to-allow-configmaps-mounts-on-upload-scripts-or-envs"></a>
- configMap
# To derive the experiment pod name in the experimemnt. <a href="#to-derive-the-experiment-pod-name-in-the-experimemnt" id="to-derive-the-experiment-pod-name-in-the-experimemnt"></a>
- downwardAPI
# used for chaos injection like io chaos. <a href="#used-for-chaos-injection-like-io-chaos" id="used-for-chaos-injection-like-io-chaos"></a>
- emptyDir
- hostPath
- persistentVolumeClaim
- projected
# To authenticate with different cloud providers <a href="#to-authenticate-with-different-cloud-providers" id="to-authenticate-with-different-cloud-providers"></a>
- secret

Install the SCC

$ oc create -f litmus-scc.yaml
securitycontextconstraints.security.openshift.io/litmus-scc created

Associate new service account with the SCC

To associate the new service account with the SCC, execute the below command:

$ oc adm policy add-scc-to-user litmus-scc -z litmus-admin --as system:admin -n litmus
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:litmus-scc added: "litmus-admin"

where

• -z refers to applying the command to the service account in the current project;

• add-scc-to-user ads the name of the SCC; and

• -n specifies the namespace of the target service account.