> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/3.0/security/security-templates/openshift-scc.md).

# Openshift

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

### OpenShift Security Context Constraint (SCC) <a href="#openshift-security-context-constraint-scc" id="openshift-security-context-constraint-scc"></a>

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.

{% hint style="info" %}
You can leverage all the [permissions mentioned](#run-service-account-as-a-cluster-admin) for fault execution as well as [service discovery](/harness-ai/use-harness-platform/service-discovery/user-defined-service-account.md). The SCC described below is a superset, which means only some of them are required for service discovery.
{% endhint %}

#### Create a new service account <a href="#create-a-new-service-account" id="create-a-new-service-account"></a>

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

```bash
$ oc create serviceaccount litmus-admin

serviceaccount/litmus-admin created
```

#### Run service account as a cluster admin <a href="#run-service-account-as-a-cluster-admin" id="run-service-account-as-a-cluster-admin"></a>

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.

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

```yaml
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 <a href="#install-the-scc" id="install-the-scc"></a>

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

#### Associate new service account with the SCC <a href="#associate-new-service-account-with-the-scc" id="associate-new-service-account-with-the-scc"></a>

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

```bash
$ 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.