Kubernetes Privileged Container

Your Kubernetes pod runs with securityContext.privileged: true, giving the container full access to the host kernel and effectively bypassing container isolation.

How It Works

A privileged container runs with almost the same access as a process running directly on the host. It can access all host devices, modify kernel parameters, and escape the container to access the underlying node. If an attacker compromises a privileged container (via a vulnerability in your app), they can escape to the host and compromise the entire Kubernetes node and potentially the whole cluster.

Vulnerable Code

# BAD: pod spec with privileged container
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      privileged: true  # full host access — almost never necessary

Secure Code

# GOOD: minimal security context, no privilege escalation
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      privileged: false
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      runAsUser: 1000
      readOnlyRootFilesystem: true

Real-World Example

Container escape vulnerabilities (CVE-2019-5736 runc, CVE-2022-0185 Linux kernel) are significantly more exploitable when containers are privileged. In 2022, attackers who compromised a privileged container in a Kubernetes cluster were able to escape to the node within minutes, then pivot to access secrets from other pods via the node's kubelet.

How to Prevent It

Never set privileged: true unless you have a specific, documented reason (e.g., certain CNI plugins, DaemonSets for node monitoring)
Set allowPrivilegeEscalation: false and runAsNonRoot: true as defaults for all containers
Use Pod Security Admission (PSA) to enforce baseline or restricted policies cluster-wide
Set readOnlyRootFilesystem: true to prevent attackers from writing tools to the container filesystem
Use tools like kube-bench to audit your cluster against CIS Kubernetes Benchmark

Affected Technologies

Node.jsPython

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities

Terraform State Exposed

critical

Your terraform.tfstate file is committed to your repository or stored in an unencrypted, publicly accessible location — it contains every secret and resource ID in your infrastructure.

CWE-312OWASP A02:2021

Terraform Provider Credentials Hardcoded

critical

AWS, GCP, or Azure credentials are hardcoded in your .tf files instead of using environment variables or instance roles, committing cloud access keys to version control.

CWE-798OWASP A02:2021

Kubernetes Default Service Account

medium

Pods running with the default service account inherit cluster-level RBAC permissions that are often far more powerful than the workload needs, enabling lateral movement if the pod is compromised.

CWE-269OWASP A01:2021

Helm Chart Secrets in Values

high

Passwords, API keys, and other secrets are hardcoded directly in Helm values.yaml files, which get committed to version control and exposed to anyone with repository access.

CWE-798OWASP A07:2021