Kube-faq

# Let root containers run in a specific namespace (OKD / OpenShift)

It's not advised, but there are cases where you have to run Pods as root. There's a SecurityContextConstraint (SCC) in OpenShift handling this:

`oc get scc anyuid -o yaml`

```yaml

kind: SecurityContextConstraints

apiVersion: security.openshift.io/v1

metadata:

  annotations:

    include.release.openshift.io/ibm-cloud-managed: "true"

    include.release.openshift.io/self-managed-high-availability: "true"

    include.release.openshift.io/single-node-developer: "true"

    kubernetes.io/description: anyuid provides all features of the restricted SCC but allows users to run with any UID and any GID.

    release.openshift.io/create-only: "true"

  name: anyuid

allowHostDirVolumePlugin: false

allowHostIPC: false

allowHostNetwork: false

allowHostPID: false

allowHostPorts: false

allowPrivilegeEscalation: true

allowPrivilegedContainer: false

allowedCapabilities: null

defaultAddCapabilities: null

fsGroup:

  type: RunAsAny

groups:

- system:cluster-admins

priority: 10

readOnlyRootFilesystem: false

requiredDropCapabilities:

- MKNOD

runAsUser:

  type: RunAsAny

seLinuxContext:

  type: MustRunAs

supplementalGroups:

  type: RunAsAny

users: []

volumes:

- configMap

- downwardAPI

- emptyDir

- persistentVolumeClaim

- projected

```

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

The best and practicable way is to create a special namespace for this *evil* pods and restrict the access to this namespaces as wide as you can.

## Set this with commandline tools

OK, we make a namespace `evilone-notsecure`

`oc new-project evilone-notsecure --description="Evil Project for root Containers (need anyuid)" --display-name="Evil One (anyuid!)"`

Then we set the SCC for the default Systemaccount in this project:

`oc adm policy add-scc-to-user -z default -n evilone-notsecure anyuid`

## Set this with an RoleBinding object (for GitOps people ;-))

The above command creates the following RoleBinding in the namespace:

```yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: system:openshift:scc:anyuid

  namespace: evilone-notsecure

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: system:openshift:scc:anyuid

subjects:

- kind: ServiceAccount

  name: default

  namespace: evilone-notsecure

```

You can import this manually with `oc apply -f filename.yaml`

## Verify anyuid rights in your cluster

You can search for the RoleBinding:

`oc get rolebindings -A | grep ClusterRole/system:openshift:scc:anyuid`

**Attention:** there might be a ClusterRoleRinding with additional namespaces or ServiceAccounts:

`oc get clusterrolebindings -A | grep ClusterRole/system:openshift:scc:anyuid` and then look at this object!