Lab 02 — Remove Privileged Containers

Mission Information

Item	Details
Lab ID	K8S-WORKLOAD-LAB-02
Difficulty	Intermediate
Estimated Time	3–4 Hours
Environment	Kubernetes Cluster
Platform	Amazon EKS / Azure AKS / Google GKE / kind / minikube
Cost	Free for Local Cluster / Cloud Charges May Apply
Primary Role	Kubernetes Security Engineer
Module	Kubernetes Workload and Pod Security
Previous Lab	Lab 01 — Secure Pod Configuration
Next Lab	Lab 03 — Configure Security Context

Mission Scenario

CloudNova Technologies recently completed an internal Kubernetes workload security review.

The review identified several operational tools and legacy applications running with:

securityContext:
  privileged: true

The application teams originally enabled privileged mode to resolve permission problems during development. The setting was never removed before the workloads reached production.

During a Purple Team exercise, security engineers demonstrated that a compromised privileged container could potentially:

• Access host devices
• Interact with sensitive kernel interfaces
• Modify host networking
• Mount additional filesystems
• Access node-level resources
• Weaken container isolation
• Establish persistence on the worker node
• Affect workloads running outside the compromised Pod

The CISO has classified privileged containers as a critical production risk.

Your mission is to identify an intentionally privileged workload, demonstrate why it is dangerous, remove privileged mode, grant only the minimum required capabilities, enforce admission controls, and produce an enterprise remediation report.

Learning Objectives

By completing this lab, you will learn how to:

• Identify privileged Kubernetes containers
• Understand how privileged mode affects container isolation
• Inspect runtime privileges and Linux capabilities
• Assess access to host devices and kernel interfaces
• Replace privileged containers with least-privilege configurations
• Disable privilege escalation
• Drop unnecessary Linux capabilities
• Add only explicitly required capabilities
• Prevent host namespace access
• Prevent unsafe volume mounts
• Enforce the Restricted Pod Security Standard
• Validate remediated workload behaviour
• Produce an enterprise privileged-container assessment

Enterprise Architecture

Before Remediation

Kubernetes Worker Node
        │
        ├── Host Kernel
        ├── Host Devices
        ├── Host Network
        ├── Host Filesystem
        │
        └── Privileged Container
                  │
                  ├── Broad Linux Capabilities
                  ├── Device Access
                  ├── Kernel Interface Access
                  └── Reduced Isolation


After Remediation

Kubernetes Worker Node
        │
        └── Hardened Application Pod
                  │
                  ├── privileged: false
                  ├── allowPrivilegeEscalation: false
                  ├── runAsNonRoot: true
                  ├── capabilities.drop: ALL
                  ├── readOnlyRootFilesystem: true
                  └── seccompProfile: RuntimeDefault

Privileged Container Risk Model

Application Compromise

        │
        ▼

Privileged Container Access

        │
        ▼

Host-Level Interfaces Exposed

        │
        ├── Devices
        ├── Kernel Controls
        ├── Network Configuration
        └── Mounted Host Resources

        │
        ▼

Potential Node Compromise

        │
        ▼

Cluster-Wide Impact

Lab Outcomes

By the end of this lab, you will have:

• Created an isolated assessment namespace
• Deployed an intentionally privileged container
• Inspected its runtime security configuration
• Compared privileged and non-privileged capabilities
• Reviewed host device visibility
• Tested privileged operations safely
• Identified additional dangerous Pod settings
• Removed privileged mode
• Applied a least-privilege security context
• Enforced restricted Pod admission
• Validated that the remediated workload remained functional
• Produced an enterprise remediation report

Important Safety Notice

Perform this lab only in:

• A dedicated training cluster
• A local kind or minikube environment
• A non-production cloud cluster
• An environment where you are authorised to deploy privileged workloads

Do not perform host modification, filesystem mounting, kernel changes, or destructive node operations.

The validation steps in this lab are designed to demonstrate exposure without intentionally modifying the Kubernetes worker node.

Prerequisites

Before starting, ensure that you have:

• Completed Lab 01 — Secure Pod Configuration
• A running Kubernetes cluster
• kubectl installed and configured
• Permission to create namespaces and Pods
• Permission to update namespace Pod Security labels
• Basic understanding of Linux permissions and capabilities
• Visual Studio Code or another YAML editor

Tools Used

Tool	Purpose
kubectl	Deploy, inspect, and validate Kubernetes workloads
Kubernetes Cluster	Run insecure and remediated containers
busybox	Perform runtime validation
capsh	Inspect Linux capabilities where available
Visual Studio Code	Create and edit YAML manifests
Git Bash / PowerShell	Execute commands

Recommended Lab File Structure

lab-02-remove-privileged-containers/
├── 01-namespace.yaml
├── 02-privileged-pod.yaml
├── 03-baseline-pod.yaml
├── 04-remediated-deployment.yaml
├── 05-remediated-service.yaml
├── evidence/
└── privileged-container-report.md

Task 01 — Verify Cluster Health

Confirm cluster access.

kubectl cluster-info

Review the worker nodes.

kubectl get nodes -o wide

Record the Kubernetes version.

kubectl version

Confirm:

• The Kubernetes API is reachable.
• Required nodes report Ready.
• You are working in an authorised training environment.

Task 02 — Create the Assessment Namespace

Create 01-namespace.yaml.

apiVersion: v1
kind: Namespace
metadata:
  name: privileged-assessment
  labels:
    environment: training
    owner: cloud-security
    purpose: privileged-container-assessment
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Apply the namespace.

kubectl apply -f 01-namespace.yaml

Verify its labels.

kubectl get namespace privileged-assessment --show-labels

Why Privileged Enforcement Is Temporarily Used

The namespace temporarily permits privileged workloads so that you can deploy and assess the intentionally insecure Pod.

The cluster will still generate audit or warning messages for violations of the Restricted Pod Security Standard.

After the insecure workload is removed, you will change the namespace to restricted enforcement.

Task 03 — Create an Intentionally Privileged Pod

Create 02-privileged-pod.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: privileged-tool
  namespace: privileged-assessment
  labels:
    app: privileged-tool
    security-status: non-compliant
spec:
  restartPolicy: Never
  containers:
    - name: privileged-tool
      image: busybox:1.36
      command:
        - sh
        - -c
        - sleep 3600
      securityContext:
        privileged: true
      resources:
        requests:
          cpu: 10m
          memory: 16Mi
        limits:
          cpu: 100m
          memory: 64Mi

Apply the Pod.

kubectl apply -f 02-privileged-pod.yaml

Observe any Pod Security warnings.

Wait for the Pod to start.

kubectl wait \
  --for=condition=Ready \
  pod/privileged-tool \
  -n privileged-assessment \
  --timeout=120s

Verify it.

kubectl get pod privileged-tool -n privileged-assessment -o wide

Task 04 — Inspect the Privileged Configuration

Review the Pod manifest.

kubectl get pod privileged-tool \
  -n privileged-assessment \
  -o yaml

Inspect the privileged setting directly.

kubectl get pod privileged-tool \
  -n privileged-assessment \
  -o jsonpath='{.spec.containers[0].securityContext.privileged}{"\n"}'

Expected:

true

Describe the Pod.

kubectl describe pod privileged-tool -n privileged-assessment

Record:

• Namespace
• Pod name
• Node
• Container image
• Security context
• Service Account
• Mounted volumes
• Pod Security warnings

Task 05 — Review the Runtime Identity

Open a shell inside the container.

kubectl exec -it privileged-tool \
  -n privileged-assessment \
  -- sh

Run:

id

whoami

cat /proc/1/status | grep -E 'Uid|Gid'

Expected:

uid=0(root)

Exit the shell.

exit

Security Finding

Privileged containers commonly run as root and receive broad access to operating-system interfaces.

The combination of root execution and privileged mode greatly increases the potential impact of application compromise.

Task 06 — Inspect Linux Capabilities

Review the process capability fields.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- sh -c "grep '^Cap' /proc/1/status"

Record:

CapInh
CapPrm
CapEff
CapBnd
CapAmb

In a privileged container, the effective and bounding capability sets are typically much broader than in a standard container.

If capsh is available in your selected image, run:

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- capsh --print

If the command is unavailable, use the /proc/1/status output as evidence.

Task 07 — Review Device Visibility

List visible devices.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- ls -la /dev

Count the visible entries.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- sh -c "ls /dev | wc -l"

Record notable device entries.

Depending on the runtime and cluster platform, a privileged container may receive significantly broader device visibility than a normal container.

Do not write to any device.

Task 08 — Review Kernel Interface Visibility

Inspect selected kernel and system paths.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- ls -la /proc/sys

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- ls -la /sys

Review mount information.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- cat /proc/mounts

Do not change any kernel parameter.

Security Finding

Privileged containers may have access to kernel-facing interfaces that should not be exposed to ordinary application workloads.

Task 09 — Test a Harmless Privileged Operation

Attempt to create a character device inside /tmp.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- mknod /tmp/test-null c 1 3

Verify the device entry.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- ls -l /tmp/test-null

Expected result in many privileged environments:

crw-r--r--

Remove the test entry.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- rm -f /tmp/test-null

Why This Matters

The mknod operation demonstrates access to a powerful Linux capability.

A normal application container rarely requires the ability to create device nodes.

Task 10 — Inspect Privilege Escalation Protection

Check whether allowPrivilegeEscalation was configured.

kubectl get pod privileged-tool \
  -n privileged-assessment \
  -o jsonpath='{.spec.containers[0].securityContext.allowPrivilegeEscalation}{"\n"}'

An empty result indicates it was not explicitly disabled.

Check the runtime process status.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- sh -c "grep '^NoNewPrivs' /proc/1/status"

A value of 0 indicates that no-new-privileges protection is not active.

Task 11 — Review Seccomp Status

Check the manifest.

kubectl get pod privileged-tool \
  -n privileged-assessment \
  -o jsonpath='{.spec.securityContext.seccompProfile.type}{"\n"}'

Check runtime status.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- sh -c "grep '^Seccomp' /proc/1/status"

Privileged workloads may bypass or weaken the syscall restrictions normally expected for standard containers, depending on the runtime configuration.

Record the result.

Task 12 — Review Service Account Token Exposure

Check the assigned Service Account.

kubectl get pod privileged-tool \
  -n privileged-assessment \
  -o jsonpath='{.spec.serviceAccountName}{"\n"}'

Inspect the token directory.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- ls -la /var/run/secrets/kubernetes.io/serviceaccount

Security Finding

A privileged workload with a mounted Kubernetes API token combines:

• Host-level runtime exposure
• Kubernetes API credentials

This creates multiple potential paths for privilege abuse.

Task 13 — Create a Standard Comparison Pod

Create 03-baseline-pod.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: baseline-tool
  namespace: privileged-assessment
  labels:
    app: baseline-tool
spec:
  restartPolicy: Never
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: baseline-tool
      image: busybox:1.36
      command:
        - sh
        - -c
        - sleep 3600
      securityContext:
        privileged: false
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
      resources:
        requests:
          cpu: 10m
          memory: 16Mi
        limits:
          cpu: 50m
          memory: 32Mi
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir:
        sizeLimit: 10Mi

Apply the Pod.

kubectl apply -f 03-baseline-pod.yaml

Wait for it.

kubectl wait \
  --for=condition=Ready \
  pod/baseline-tool \
  -n privileged-assessment \
  --timeout=120s

Task 14 — Compare Runtime Identities

Check the privileged Pod.

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- id

Check the baseline Pod.

kubectl exec baseline-tool \
  -n privileged-assessment \
  -- id

Expected comparison:

Pod	Expected Identity
privileged-tool	Root
baseline-tool	Non-root UID 10001

Task 15 — Compare Effective Capabilities

Privileged container:

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- sh -c "grep '^CapEff' /proc/1/status"

Baseline container:

kubectl exec baseline-tool \
  -n privileged-assessment \
  -- sh -c "grep '^CapEff' /proc/1/status"

Expected baseline result:

CapEff: 0000000000000000

Document the difference.

Task 16 — Compare Device Visibility

Privileged container:

kubectl exec privileged-tool \
  -n privileged-assessment \
  -- sh -c "ls /dev | sort"

Baseline container:

kubectl exec baseline-tool \
  -n privileged-assessment \
  -- sh -c "ls /dev | sort"

Compare:

• Number of devices
• Type of devices
• Access permissions
• Runtime differences

Results vary by Kubernetes distribution and container runtime.

Task 17 — Repeat the Device Creation Test

Run the test in the baseline container.

kubectl exec baseline-tool \
  -n privileged-assessment \
  -- mknod /tmp/test-null c 1 3

Expected:

Operation not permitted

This demonstrates that the hardened container does not have the capability required to create device nodes.

Task 18 — Assess Additional Dangerous Settings

Privileged mode is not the only setting that can weaken container isolation.

Review the following Pod configuration risks.

Setting	Risk
hostPID: true	Exposes host process namespace
hostIPC: true	Exposes host inter-process communication
hostNetwork: true	Shares the node network namespace
hostPath volume	Exposes node filesystem paths
allowPrivilegeEscalation: true	Permits processes to gain additional privilege
runAsUser: 0	Runs the application as root
capabilities.add	Grants kernel-level privileges
seccompProfile: Unconfined	Removes syscall filtering
procMount: Unmasked	Exposes sensitive /proc paths

Inspect the current privileged Pod.

kubectl get pod privileged-tool \
  -n privileged-assessment \
  -o jsonpath='{.spec.hostPID}{"\n"}{.spec.hostIPC}{"\n"}{.spec.hostNetwork}{"\n"}'

Task 19 — Record the Initial Security Assessment

Complete the privileged workload assessment.

Control	Result	Risk
Privileged mode disabled	Failed	Critical
Runs as non-root	Failed	High
Privilege escalation disabled	Failed	High
Linux capabilities dropped	Failed	Critical
Seccomp configured	Failed or weakened	High
Root filesystem read-only	Failed	High
Service Account token disabled	Failed	Medium
Host namespaces disabled	Passed if absent	Critical if enabled
HostPath volumes absent	Passed	Critical if present
Resource controls configured	Passed	Medium
Device access restricted	Failed	Critical

Initial classification:

Non-Compliant

Task 20 — Delete the Insecure Workloads

Delete both assessment Pods.

kubectl delete pod privileged-tool baseline-tool \
  -n privileged-assessment

Verify removal.

kubectl get pods -n privileged-assessment

Task 21 — Enforce Restricted Pod Security

Update the namespace labels.

kubectl label namespace privileged-assessment \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/audit-version=latest \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version=latest \
  --overwrite

Verify:

kubectl get namespace privileged-assessment --show-labels

Task 22 — Validate Admission Rejection

Attempt to redeploy the privileged Pod.

kubectl apply -f 02-privileged-pod.yaml

Expected:

• Admission is denied.
• The error references the Restricted Pod Security Standard.
• The message may identify several violations.

Typical violations include:

privileged
allowPrivilegeEscalation
runAsNonRoot
capabilities
seccompProfile

Capture the rejection as evidence.

Verify the Pod was not created.

kubectl get pod privileged-tool -n privileged-assessment

Task 23 — Create the Remediated Deployment

Create 04-remediated-deployment.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-tool
  namespace: privileged-assessment
  labels:
    app: secure-tool
    security-status: compliant
spec:
  replicas: 1
  selector:
    matchLabels:
      app: secure-tool
  template:
    metadata:
      labels:
        app: secure-tool
        security-status: compliant
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        fsGroup: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: secure-tool
          image: busybox:1.36
          command:
            - sh
            - -c
            - |
              while true; do
                echo "secure workload is running" > /tmp/status.txt
                sleep 30
              done
          securityContext:
            privileged: false
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          resources:
            requests:
              cpu: 10m
              memory: 16Mi
            limits:
              cpu: 50m
              memory: 32Mi
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 10Mi

Apply it.

kubectl apply -f 04-remediated-deployment.yaml

Verify the rollout.

kubectl rollout status deployment/secure-tool \
  -n privileged-assessment

List the Pod.

kubectl get pods -n privileged-assessment \
  -l app=secure-tool

Task 24 — Validate Privileged Mode Is Disabled

Store the Pod name in Git Bash.

POD_NAME=$(kubectl get pod \
  -n privileged-assessment \
  -l app=secure-tool \
  -o jsonpath='{.items[0].metadata.name}')

PowerShell:

$POD_NAME = kubectl get pod `
  -n privileged-assessment `
  -l app=secure-tool `
  -o jsonpath='{.items[0].metadata.name}'

Inspect the setting.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o jsonpath='{.spec.containers[0].securityContext.privileged}{"\n"}'

Expected:

false

Task 25 — Validate Non-Root Execution

Check the process identity.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- id

Expected:

uid=10001
gid=10001

Confirm the process does not run as root.

Task 26 — Validate Privilege Escalation Protection

Check the manifest setting.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o jsonpath='{.spec.containers[0].securityContext.allowPrivilegeEscalation}{"\n"}'

Expected:

false

Check process status.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- sh -c "grep '^NoNewPrivs' /proc/1/status"

Expected:

NoNewPrivs: 1

Task 27 — Validate Dropped Capabilities

Inspect the manifest.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o jsonpath='{.spec.containers[0].securityContext.capabilities.drop}{"\n"}'

Expected:

["ALL"]

Inspect runtime capabilities.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- sh -c "grep '^CapEff' /proc/1/status"

Expected:

CapEff: 0000000000000000

Task 28 — Validate the Device Creation Restriction

Attempt the same operation used in the privileged container.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- mknod /tmp/test-null c 1 3

Expected:

Operation not permitted

This confirms that the remediated workload no longer has the required Linux capability.

Task 29 — Validate the Read-Only Root Filesystem

Attempt to create a file under /etc.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- touch /etc/blocked.txt

Expected:

Read-only file system

Validate the approved writable path.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- cat /tmp/status.txt

Expected:

secure workload is running

Task 30 — Validate Seccomp Protection

Inspect the configured profile.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o jsonpath='{.spec.securityContext.seccompProfile.type}{"\n"}'

Expected:

RuntimeDefault

Review runtime status.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- sh -c "grep '^Seccomp' /proc/1/status"

A Seccomp value of 2 normally indicates filtering is active.

Task 31 — Validate Service Account Token Protection

Check the Pod setting.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o jsonpath='{.spec.automountServiceAccountToken}{"\n"}'

Expected:

false

Check the token path.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- sh -c "ls /var/run/secrets/kubernetes.io/serviceaccount"

Expected:

No such file or directory

Task 32 — Validate Host Namespace Isolation

Review the Pod specification.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o jsonpath='{.spec.hostPID}{"\n"}{.spec.hostIPC}{"\n"}{.spec.hostNetwork}{"\n"}'

Empty or false values indicate that host namespace sharing is not enabled.

Confirm:

Control	Expected
hostPID	False or unset
hostIPC	False or unset
hostNetwork	False or unset

Task 33 — Validate Absence of HostPath Volumes

Inspect all volume types.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o jsonpath='{.spec.volumes}{"\n"}'

Confirm:

• Only the approved emptyDir volume exists.
• No hostPath volume is mounted.
• No node filesystem path is exposed.

Task 34 — Review All Security Controls

Export the effective Pod manifest.

kubectl get pod "$POD_NAME" \
  -n privileged-assessment \
  -o yaml

Confirm the presence of:

automountServiceAccountToken: false

runAsNonRoot: true

runAsUser: 10001

seccompProfile:
  type: RuntimeDefault

privileged: false

allowPrivilegeEscalation: false

readOnlyRootFilesystem: true

capabilities:
  drop:
    - ALL

Task 35 — Understand Capability-Based Exceptions

Some infrastructure workloads may require a specific Linux capability.

Examples may include:

• Network troubleshooting tools
• Time synchronisation agents
• Low-level networking components
• Certain storage or security agents

Do not use privileged mode when one narrowly scoped capability is sufficient.

Example:

securityContext:
  privileged: false
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE

Exception Principles

Any added capability should have:

• A documented technical requirement
• Application-owner approval
• Security-team approval
• Testing evidence
• A defined review date
• Monitoring requirements
• A remediation or retirement plan

Do not add capabilities merely to resolve an unexplained application error.

Task 36 — Compare the Workloads

Security Control	Privileged Workload	Remediated Workload
Privileged mode	Enabled	Disabled
Runtime user	Root	Non-root
Privilege escalation	Available	Disabled
Effective capabilities	Broad	None
Device node creation	Permitted in many environments	Denied
Root filesystem	Writable	Read-only
Writable paths	Broad	Explicit /tmp volume
Seccomp	Missing or weakened	RuntimeDefault
Service Account token	Mounted	Disabled
Host namespaces	Not explicitly protected	Disabled by default
HostPath access	None in sample	None
Pod Security admission	Allowed temporarily	Restricted enforcement
Security classification	Non-Compliant	Compliant

Task 37 — Simulate a Compromised Remediated Container

Assume an attacker has gained command execution.

Attempt to become root.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- id

Expected:

• Non-root identity.

Attempt to create a device.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- mknod /tmp/test-device c 1 3

Expected:

Operation not permitted

Attempt to modify system configuration.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- sh -c "echo malicious >> /etc/passwd"

Expected:

Read-only file system

Attempt to locate a Kubernetes token.

kubectl exec "$POD_NAME" \
  -n privileged-assessment \
  -- sh -c "find /var/run/secrets -type f 2>/dev/null"

Expected:

• No Service Account token.

Task 38 — Analyse the Reduced Attack Surface

Attack Technique	Remediating Control	Outcome
Access broad host interfaces	Privileged mode disabled	Reduced
Create device nodes	Capabilities dropped	Blocked
Gain additional privileges	Privilege escalation disabled	Blocked
Operate as root	Non-root execution	Prevented
Modify system files	Read-only root filesystem	Blocked
Use unrestricted syscalls	RuntimeDefault seccomp	Reduced
Access Kubernetes credentials	Token automount disabled	Prevented
Access node filesystem	No HostPath volume	Prevented
Enter host process namespace	hostPID disabled	Prevented
Modify host networking	No privileged mode or host network	Reduced

Task 39 — Perform the Enterprise Security Assessment

Complete the assessment.

Control Domain	Validation	Status
Privileged mode	Explicitly disabled
Runtime identity	Non-root UID 10001
Privilege escalation	NoNewPrivs: 1
Linux capabilities	CapEff zero
Device operations	mknod denied
Root filesystem	Protected writes denied
Writable storage	Limited to approved emptyDir
Seccomp	RuntimeDefault active
Service Account token	Not mounted
Host namespace isolation	Enabled through defaults
Host filesystem access	No HostPath volumes
Admission control	Restricted standard enforced
Resource governance	Requests and limits configured

Use one of the following ratings:

• Compliant
• Requires Improvement
• Non-Compliant

Task 40 — Produce the Privileged Container Remediation Report

Create privileged-container-report.md.

Assessment Title:
Privileged Container Remediation Review

Cluster Name:

Namespace:
privileged-assessment

Assessment Date:

Assessor:

Original Workload:
privileged-tool

Remediated Workload:
secure-tool

Original Privileged Configuration:

Business Requirement for Privileged Access:

Runtime Identity Findings:

Capability Findings:

Device Visibility Findings:

Kernel Interface Findings:

Service Account Token Findings:

Admission Control Findings:

Remediation Actions:

Security Controls Implemented:

Validation Results:

Residual Risks:

Approved Exceptions:

Recommendations:

Overall Security Rating:

Production Decision:

Approved

Conditionally Approved

Rejected

Task 41 — Evidence Collection

Collect evidence for:

• Cluster and node health
• Namespace Pod Security labels
• Original privileged manifest
• Pod Security warning output
• Privileged runtime identity
• Privileged capability output
• Device visibility comparison
• mknod test in the privileged Pod
• mknod denial in the remediated Pod
• Restricted admission rejection
• Remediated Deployment manifest
• Non-root validation
• Read-only filesystem validation
• Seccomp validation
• Service Account token validation
• Host namespace validation
• HostPath volume review
• Final remediation report

Suggested filenames:

01-cluster-health.txt
02-namespace-labels.txt
03-privileged-pod.yaml
04-privileged-runtime-identity.txt
05-privileged-capabilities.txt
06-device-visibility.txt
07-privileged-operation-test.txt
08-admission-rejection.txt
09-remediated-deployment.yaml
10-non-root-validation.txt
11-capability-remediation.txt
12-readonly-validation.txt
13-seccomp-validation.txt
14-token-validation.txt
15-host-isolation-review.txt
16-remediation-report.md

Task 42 — Clean Up

Delete the remediated Deployment.

kubectl delete deployment secure-tool \
  -n privileged-assessment

Delete any remaining Pods.

kubectl delete pod privileged-tool baseline-tool \
  -n privileged-assessment \
  --ignore-not-found

Delete the namespace.

kubectl delete namespace privileged-assessment

Verify cleanup.

kubectl get namespace privileged-assessment

Expected:

NotFound

Enterprise Privileged Workload Review Checklist

Control	Status
Privileged containers inventoried	☐
Business justification reviewed	☐
Privileged mode removed where unnecessary	☐
Containers run as non-root	☐
Privilege escalation disabled	☐
All capabilities dropped by default	☐
Required capability exceptions documented	☐
RuntimeDefault seccomp enabled	☐
Root filesystem read-only	☐
Writable directories explicitly mounted	☐
Service Account token disabled where unnecessary	☐
Host PID disabled	☐
Host IPC disabled	☐
Host networking disabled	☐
HostPath volumes prohibited	☐
Restricted Pod Security Standard enforced	☐
Runtime behaviour validated	☐
Remediation evidence collected	☐
Production approval documented	☐

Risk Classification

Critical

Examples:

• Privileged production application with no approved justification
• Privileged container with HostPath mounted to /
• Privileged container using host PID and host networking
• Privileged workload with broad Kubernetes API permissions
• Privileged workload exposed to untrusted users

High

Examples:

• Root container with multiple added capabilities
• Privilege escalation not disabled
• Seccomp unconfined
• Host namespace sharing
• Unnecessary device access

Medium

Examples:

• Missing resource limits
• Service Account token mounted unnecessarily
• Incomplete exception documentation
• Missing runtime validation

Low

Examples:

• Naming inconsistencies
• Missing ownership labels
• Evidence-format improvements
• Review-date documentation gaps

Remediation Priorities

Immediate

• Remove privileged mode from standard application workloads.
• Block new privileged Pods using admission controls.
• Isolate any privileged workload that cannot be immediately removed.
• Revoke unnecessary Service Account permissions.
• Investigate privileged workloads exposed to untrusted input.

Short-Term

• Replace broad privilege with specific Linux capabilities.
• Enforce non-root execution.
• Apply RuntimeDefault seccomp.
• Remove HostPath mounts and host namespace access.
• Introduce security-context templates.

Long-Term

• Enforce policies using Kyverno, Gatekeeper, or another admission controller.
• Continuously scan manifests for privileged settings.
• Manage security policies through GitOps.
• Review approved exceptions regularly.
• Monitor runtime behaviour using tools such as Falco or Cilium Tetragon.
• Include privileged-container tests in CI/CD pipelines.

Skills Developed

By completing this lab, you will be able to:

• Identify privileged Kubernetes containers
• Assess the runtime impact of privileged mode
• Inspect Linux capabilities
• Compare privileged and hardened workloads
• Validate access to devices and kernel interfaces
• Remove unnecessary privilege
• Apply non-root execution
• Disable privilege escalation
• Drop all Linux capabilities
• Use capability-based exceptions responsibly
• Apply seccomp protection
• Enforce restricted Pod admission
• Assess host namespace and HostPath risks
• Produce enterprise remediation evidence
• Approve or reject workloads for production

Knowledge Check

Question 1

What does privileged: true do to a Kubernetes container?

• A. It only increases CPU resources.
• B. It grants the container broad access to host-level interfaces and weakens normal container isolation.
• C. It encrypts the container filesystem.
• D. It disables the Service Account.

Answer: B

Question 2

What is the preferred alternative when an application requires one specific Linux privilege?

• A. Enable privileged mode.
• B. Grant all capabilities.
• C. Drop all capabilities and add only the explicitly required capability.
• D. Enable host networking.

Answer: C

Question 3

Which security setting prevents a process from gaining additional privileges?

• A. hostPID: true
• B. allowPrivilegeEscalation: false
• C. privileged: true
• D. runAsUser: 0

Answer: B

Question 4

Why should hostPath volumes be treated as high risk?

• A. They increase DNS traffic.
• B. They expose directories from the Kubernetes worker node to the container.
• C. They prevent Pod scheduling.
• D. They automatically enable TLS.

Answer: B

Question 5

What is the recommended default Linux capability configuration?

capabilities:
  drop:
    - ALL

• A. Drop all capabilities and add back only those with an approved requirement
• B. Add every capability
• C. Run the container as root
• D. Enable privileged mode

Answer: A

Question 6

What is the purpose of the Restricted Pod Security Standard?

• A. To increase Pod replicas
• B. To enforce baseline workload-hardening requirements and reject high-risk Pod configurations
• C. To create cloud load balancers
• D. To manage Persistent Volumes

Answer: B

Question 7

Which result indicates that privilege escalation protection is active?

• A. NoNewPrivs: 0
• B. NoNewPrivs: 1
• C. CapEff contains multiple capabilities
• D. The process runs as UID 0

Answer: B

Question 8

Why is a privileged workload with a Kubernetes Service Account token particularly dangerous?

• A. It can combine broad runtime access with Kubernetes API credentials.
• B. It cannot communicate with Services.
• C. It automatically disables logging.
• D. It reduces worker-node permissions.

Answer: A

Lab Summary

In this lab, you deployed and assessed an intentionally privileged Kubernetes container.

You examined:

• Root execution
• Broad Linux capabilities
• Device visibility
• Kernel interface exposure
• Privilege escalation
• Seccomp status
• Service Account token access

You then removed the privileged workload and deployed a hardened replacement using:

• privileged: false
• Non-root execution
• allowPrivilegeEscalation: false
• capabilities.drop: ALL
• readOnlyRootFilesystem: true
• RuntimeDefault seccomp
• Disabled Service Account token mounting
• Dedicated writable temporary storage
• CPU and memory controls
• Restricted Pod Security admission

The remediated workload remained functional while significantly reducing the potential impact of application compromise.

Privileged containers should be treated as exceptional infrastructure components, not normal application workloads. Every exception must have a documented requirement, formal approval, compensating controls, continuous monitoring, and a defined review date.

What’s Next?

Next Lab: Lab 03 — Configure Security Context

In the next lab, you will configure Pod-level and container-level security contexts in greater depth, including user and group identities, filesystem ownership, seccomp profiles, privilege escalation controls, Linux capabilities, and secure volume permissions for enterprise applications.