Lab 03 — Configure Security Context

Mission Information

Item	Details
Lab ID	K8S-WORKLOAD-LAB-03
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 Security
Previous Lab	Lab 02 — Remove Privileged Containers
Next Lab	Lab 04 — Harden Production Pods

Mission Scenario

CloudNova Technologies is preparing to migrate over 200 microservices into a new enterprise Kubernetes platform.

During a production readiness review, the Platform Security team discovered that application teams were using inconsistent security settings across workloads:

Some Pods run as root.
Others disable privilege escalation, while many do not.
Linux capabilities vary between applications.
Filesystem ownership differs across environments.
Seccomp profiles are missing on many workloads.
Some Pods mount writable root filesystems unnecessarily.
Shared storage permissions are inconsistent.

These inconsistencies make the Kubernetes environment difficult to secure, audit, and support.

To establish a secure enterprise baseline, the CISO has mandated that every workload must use standardized Security Contexts following the principles of:

Least Privilege
Zero Trust
Immutable Infrastructure
Pod Security Standards
CIS Kubernetes Benchmark

As the Kubernetes Security Engineer, your mission is to deploy insecure workloads, analyse their runtime behaviour, implement secure Pod and Container Security Contexts, validate each security control, and produce an enterprise workload security assessment.

Learning Objectives

By completing this lab, you will learn how to:

Understand Pod Security Contexts
Understand Container Security Contexts
Configure runAsNonRoot
Configure runAsUser
Configure runAsGroup
Configure fsGroup
Configure supplementalGroups
Configure seccomp profiles
Configure Linux capabilities
Configure privilege escalation
Configure ReadOnly Root Filesystem
Validate Security Contexts
Troubleshoot permission issues
Produce an enterprise workload security assessment

Enterprise Architecture

                  Kubernetes Cluster

                         │

               Production Namespace

                         │

             Hardened Kubernetes Pod

        ┌─────────────────────────────────┐

        │      Pod Security Context        │

        │---------------------------------│
        │ runAsNonRoot                    │
        │ runAsUser                       │
        │ runAsGroup                      │
        │ fsGroup                         │
        │ supplementalGroups              │
        │ seccompProfile                  │
        └─────────────────────────────────┘

                         │

        ┌─────────────────────────────────┐

        │  Container Security Context     │

        │---------------------------------│
        │ allowPrivilegeEscalation        │
        │ readOnlyRootFilesystem          │
        │ capabilities                    │
        │ privileged                      │
        └─────────────────────────────────┘

                         │

                Enterprise Application

Security Context Hierarchy

Kubernetes Pod

        │

        ▼

Pod Security Context

        │

        ▼

Container Security Context

        │

        ▼

Linux Kernel

        │

        ▼

Application Process

Lab Outcomes

By the end of this lab, you will have:

Compared insecure and secure workloads
Configured Pod Security Contexts
Configured Container Security Contexts
Implemented non-root execution
Configured filesystem ownership
Restricted Linux capabilities
Enabled seccomp
Disabled privilege escalation
Configured read-only filesystems
Validated runtime configuration
Produced an enterprise security assessment report

Prerequisites

Before beginning this lab, ensure that you have:

Completed Labs 01 and 02
A running Kubernetes cluster
kubectl installed
Visual Studio Code
Git Bash or PowerShell
Basic knowledge of Linux users and permissions

Tools Used

Tool	Purpose
Kubernetes	Workload deployment
kubectl	Cluster administration
BusyBox	Runtime validation
nginx-unprivileged	Secure web application
Visual Studio Code	YAML editing
Git Bash / PowerShell	Command execution

Recommended Lab Structure

lab-03-configure-security-context/

│

├── 01-namespace.yaml

├── 02-insecure-pod.yaml

├── 03-secure-deployment.yaml

├── 04-service.yaml

├── 05-test-pod.yaml

├── evidence/

└── security-context-report.md

Task 01 — Verify Cluster Health

Verify cluster connectivity.

kubectl cluster-info

kubectl get nodes

Confirm:

API Server reachable
Worker nodes Ready
Networking healthy

Task 02 — Create the Security Assessment Namespace

Create:

apiVersion: v1
kind: Namespace

metadata:
  name: security-context

Apply.

kubectl apply -f 01-namespace.yaml

Verify.

kubectl get namespace

Task 03 — Deploy an Insecure Application

Deploy an application without a Security Context.

Example:

containers:

- image: nginx

  name: web

Deploy.

kubectl apply -f 02-insecure-pod.yaml

Verify.

kubectl get pods

Task 04 — Review Runtime Identity

Connect to the Pod.

kubectl exec -it insecure-pod -- sh

Run.

id

whoami

Expected.

uid=0(root)

Exit.

exit

Task 05 — Review Existing Security Context

Inspect the Pod.

kubectl get pod insecure-pod \
-o yaml

Observe:

No securityContext configured.

Review:

kubectl describe pod insecure-pod

Task 06 — Configure Pod Security Context

Create a Deployment.

Configure:

securityContext:

  runAsNonRoot: true

  runAsUser: 10001

  runAsGroup: 10001

  fsGroup: 2000

  supplementalGroups:

  - 3000

  seccompProfile:

    type: RuntimeDefault

Apply.

kubectl apply -f 03-secure-deployment.yaml

Task 07 — Configure Container Security Context

Configure:

securityContext:

  allowPrivilegeEscalation: false

  privileged: false

  readOnlyRootFilesystem: true

  capabilities:

    drop:

    - ALL

Deploy.

Verify rollout.

Task 08 — Validate Runtime Identity

Retrieve Pod.

kubectl get pods

Connect.

kubectl exec -it secure-pod -- sh

Run.

id

Expected.

uid=10001
gid=10001

Verify:

The application no longer runs as root.

Task 09 — Validate Filesystem Permissions

Attempt.

touch /etc/test

Expected.

Read-only file system

Attempt.

touch /tmp/test

Expected.

Success if an emptyDir volume is mounted.

Task 10 — Validate Group Ownership

Review.

id

Verify:

Primary group.

Supplemental group.

Filesystem group.

Review mounted volume ownership.

ls -l

Task 11 — Validate Privilege Escalation

Review.

cat /proc/1/status

grep NoNewPrivs

Expected.

NoNewPrivs: 1

Task 12 — Validate Linux Capabilities

Review.

grep Cap /proc/1/status

Expected.

CapEff

0000000000000000

Verify Deployment.

kubectl get deployment \
-o yaml

Task 13 — Validate Seccomp

Review.

grep Seccomp /proc/1/status

Expected.

Seccomp: 2

Verify.

kubectl get pod \
-o yaml

Confirm.

RuntimeDefault

Task 14 — Validate Service Account Token

Review.

ls

/var/run/secrets/kubernetes.io

Expected.

No token mounted.

Verify.

kubectl get pod \
-o yaml

Task 15 — Configure Shared Storage

Mount.

emptyDir

Verify.

Filesystem ownership.

ls -l

Confirm.

fsGroup applied correctly.

Task 16 — Validate Application Availability

Create Service.

ClusterIP

Deploy BusyBox test Pod.

Validate.

wget

Confirm.

Application reachable.

Task 17 — Compare Security Contexts

Control	Insecure	Secure
runAsNonRoot	❌	✅
runAsUser	❌	✅
runAsGroup	❌	✅
fsGroup	❌	✅
supplementalGroups	❌	✅
allowPrivilegeEscalation	❌	✅
privileged	❌	✅
readOnlyRootFilesystem	❌	✅
capabilities.drop	❌	✅
seccomp	❌	✅

Task 18 — Simulate a Container Compromise

Attempt.

touch /etc/passwd

Expected.

Denied.

Attempt.

mknod

Expected.

Denied.

Attempt.

whoami

Expected.

Non-root.

Attempt.

Locate Kubernetes token.

Expected.

Not found.

Task 19 — Enterprise Security Assessment

Review.

Control	Status
Non-root execution
User ID configured
Group ID configured
fsGroup configured
Supplemental groups
Privilege escalation disabled
ReadOnly filesystem
Linux capabilities
Seccomp
Service Account

Classify.

Compliant
Requires Improvement
Non-Compliant

Task 20 — Produce the Assessment Report

Document.

Assessment:

Namespace:

Application:

Security Context:

Container Security Context:

Runtime User:

Runtime Groups:

Filesystem Ownership:

Capabilities:

Seccomp:

ReadOnly Filesystem:

Findings:

Recommendations:

Overall Rating:

Task 21 — Evidence Collection

Collect:

Deployment YAML
Runtime identity
Filesystem validation
Group ownership
Linux capabilities
Seccomp
Service Account
Security assessment
Final report

Task 22 — Clean Up

Delete:

kubectl delete deployment

kubectl delete service

kubectl delete namespace

Enterprise Security Context Checklist

Control	Status
runAsNonRoot	☐
runAsUser	☐
runAsGroup	☐
fsGroup	☐
supplementalGroups	☐
Privilege Escalation Disabled	☐
Privileged Disabled	☐
Linux Capabilities Dropped	☐
ReadOnly Root Filesystem	☐
RuntimeDefault Seccomp	☐
Service Account Protected	☐
Resource Limits Configured	☐
ClusterIP Service	☐

Risk Classification

Critical

Privileged containers
Root execution
No seccomp
No securityContext

High

Missing fsGroup
Writable filesystem
Missing capabilities

Medium

Missing supplemental groups
Missing limits
Missing documentation

Low

Naming improvements
Labels
Documentation

Skills Developed

After completing this lab, you will be able to:

Configure Pod Security Contexts
Configure Container Security Contexts
Configure Linux identities
Configure filesystem ownership
Configure supplemental groups
Configure seccomp
Configure Linux capabilities
Configure privilege escalation
Configure ReadOnly Root Filesystem
Validate runtime configuration
Troubleshoot permission issues
Perform enterprise workload security assessments

Knowledge Check

Question 1

Which Security Context setting prevents a container from running as root?

A. privileged
B. runAsNonRoot
C. hostNetwork
D. fsGroup

Answer: B

Question 2

Which setting defines the Linux user ID inside a container?

A. runAsUser
B. runAsGroup
C. fsGroup
D. capabilities

Answer: A

Question 3

What is the purpose of fsGroup?

A. Configure CPU resources
B. Set ownership of mounted volumes
C. Configure networking
D. Enable privileged mode

Answer: B

Question 4

Which setting prevents gaining additional Linux privileges?

A. privileged
B. allowPrivilegeEscalation: false
C. runAsUser
D. fsGroup

Answer: B

Question 5

Why should Linux capabilities be dropped?

A. Improve networking
B. Remove unnecessary kernel privileges
C. Increase storage
D. Improve scheduling

Answer: B

Question 6

Which seccomp profile is recommended for enterprise workloads?

A. Unconfined
B. RuntimeDefault
C. Localhost
D. Disabled

Answer: B

Question 7

What is the primary purpose of a Container Security Context?

A. Configure Kubernetes networking
B. Control runtime privileges for a container
C. Configure Persistent Volumes
D. Create Services

Answer: B

Question 8

Which Security Context setting helps ensure mounted volumes have the correct file ownership?

A. fsGroup
B. hostPID
C. privileged
D. capabilities

Answer: A

Lab Summary

In this lab, you configured both Pod Security Contexts and Container Security Contexts to implement a secure runtime environment for Kubernetes workloads. You applied non-root execution, explicit user and group identities, filesystem ownership controls, RuntimeDefault seccomp, disabled privilege escalation, dropped Linux capabilities, and enforced a read-only root filesystem.

You validated each security control by inspecting the running workload, testing runtime behaviour, verifying filesystem permissions, confirming Linux identities, and reviewing kernel-level protections. By standardising these settings across workloads, you established a secure and repeatable baseline that aligns with enterprise Kubernetes security best practices, the CIS Kubernetes Benchmark, and the Restricted Pod Security Standard.

What’s Next?

Next Lab: Lab 04 — Harden Production Pods

In the next lab, you will combine all workload security controls learned so far to harden a production-ready Kubernetes application, implement enterprise Pod security standards, validate compliance, and perform a comprehensive production readiness assessment.