Kubernetes Security: Why overriding SELinux is danger

This page describes a highlighted problem produced by the Docker and Kubernetes Security scanner plugin.

You could find more details on the internal page: Cloud (IaC) Security plugin

If this project has been helpful to you, please consider giving it a ⭐ on GitHub to help others discover it.

What’s wrong with overriding Kubernetes SELinux?

Assigning a custom SELinux user, role, or non-standard type to a container in Kubernetes can break the default security confinement model.

Kubernetes leverages the host operating system’s SELinux (Security-Enhanced Linux) policies to create a secure sandbox for each container. SELinux works by assigning security labels to processes and files and then enforcing rules about how they can interact. This is a form of Mandatory Access Control (MAC) that provides a robust layer of security.

Container runtimes in Kubernetes are designed to assign specific, secure SELinux labels to containers by default. The problem arises when a user manually overrides these defaults within the seLinuxOptions block of a pod’s security context. Using a custom user, role, or a type other than the ones explicitly permitted can grant the container unintended privileges. This misconfiguration can create a security vulnerability, potentially allowing a compromised container to “escape” its sandbox and access resources on the host node or other containers.

Any other type, or any value for user or role, can grant unintended privileges and allow a container to escape its sandbox.

  • container_t
  • container_init_t
  • container_kvm_t
  • container_engine_t

Using any other type without a deep understanding of Kubernetes’s SELinux policies can lead to a dangerously insecure configuration.

Solution

Remove the seLinuxOptions block entirely or keep only a permitted type from the list above.

Problematic code

apiVersion: v1
kind: Pod
metadata:
  name: app-with-custom-selinux
spec:
  securityContext:
    seLinuxOptions:
      user: "system_u"
      role: "system_r"
      type: "spc_t"
  containers:
    - name: nginx
      image: nginx:1.29-alpine

Verified code

apiVersion: v1
kind: Pod
metadata:
  name: app-secure
spec:
  securityContext:
    seLinuxOptions:
      type: container_t
  containers:
    - name: nginx
      image: nginx:1.29-alpine

Source of the description: Pod Security Standards