Lab 07 — Workload Security

You have now secured several layers of Kubernetes:

Lab 01 — Kubernetes Fundamentals
        ↓
Understand Resources

Lab 02 — Kubernetes RBAC
        ↓
Control Identity

Lab 03 — Kyverno
        ↓
Enforce Security Policy

Lab 04 — Network Policies
        ↓
Control Communication

Lab 05 — OPA Gatekeeper
        ↓
Enforce Governance

Lab 06 — Runtime Security
        ↓
Detect Suspicious Behavior

In this final Kubernetes lab, you will secure the workload itself.

The central question is:

If this application becomes compromised,
how much power will the attacker inherit?

Your objective is to reduce that power.

You will transform an intentionally weak Kubernetes workload into a hardened workload using:

Non-Root Execution

Privilege Restrictions

Linux Capability Reduction

Read-Only Filesystems

Seccomp

Service Account Controls

Secrets Protection

Resource Controls

Image Governance

Pod Security Standards

Mission Information

Difficulty: Intermediate to Advanced

Estimated Time: 90–120 minutes

Primary Skills:

Kubernetes Workload Hardening

Pod Security

Container Security

Security Contexts

Linux Capabilities

Service Account Security

Secrets Security

Resource Governance

Container Image Security

Defense in Depth

Lab Scenario

Your security team is reviewing a Kubernetes application before production deployment.

The development team has confirmed:

Application Works Correctly

but the security review identifies several concerns:

Container May Run as Root

Privilege Escalation Is Not Restricted

Linux Capabilities Are Not Minimized

Root Filesystem Is Writable

Default Service Account Is Used

Service Account Token May Be Mounted

Resource Controls Are Missing

Image Uses a Mutable Tag

Network Restrictions Are Missing

Your mission is to:

Assess
   ↓
Identify Risks
   ↓
Harden
   ↓
Deploy
   ↓
Validate
   ↓
Document

Lab Objectives

By the end of this lab, you should be able to:

Assess Kubernetes workload security
Understand Pod and container security contexts
Configure non-root execution
Prevent privilege escalation
Drop unnecessary Linux capabilities
Use read-only root filesystems
Understand seccomp protection
Review privileged containers
Review host namespace exposure
Review hostPath risks
Secure ServiceAccount usage
Reduce unnecessary token mounting
Protect Kubernetes Secrets
Configure CPU and memory controls
Evaluate container-image security
Understand Pod Security Standards
Build a workload-security baseline
Validate hardened workloads
Document professional security findings

Part 01 — Workload Security Mental Model

A Kubernetes workload is not just:

Container Image

Its effective security depends on:

Image
  +
Pod Specification
  +
Security Context
  +
Service Account
  +
RBAC
  +
Secrets
  +
Volumes
  +
Network Access
  +
Runtime Configuration

Therefore:

Secure Image
     ≠
Secure Workload

Part 02 — Why Workload Hardening Matters

Consider:

Internet
   ↓
Application
   ↓
Application Vulnerability
   ↓
Container Compromise

You cannot assume every application vulnerability will be prevented.

Instead ask:

What Happens Next?

If the workload has:

Root

Privileged Mode

Powerful Capabilities

Writable Host Mount

Powerful Service Account

Broad Network Access

the impact may become much greater.

Hardened Model

Application Compromise
        ↓
Restricted Container
        ↓
Non-Root
        ↓
Minimal Capabilities
        ↓
Restricted Filesystem
        ↓
Limited Identity
        ↓
Restricted Network
        ↓
Reduced Blast Radius

This is one of the main objectives of workload security.

Part 03 — SecurityContext

Kubernetes provides:

securityContext

for defining important security properties.

Security settings can exist at:

Pod Level

and:

Container Level

Conceptual Structure

spec:
  securityContext:
    # Pod-level controls

  containers:
    - name: application
      securityContext:
        # Container-level controls

Understanding which control belongs at which level is important.

Part 04 — Verify Your Training Environment

Run:

kubectl config current-context

Then:

kubectl cluster-info

Verify:

Correct Cluster

Training Environment

Authorized Access

Do not perform hardening experiments directly against production workloads.

Part 05 — Create the Lab Namespace

Create:

kubectl create namespace ghc-workload-security

Set it as your working namespace:

kubectl config set-context --current --namespace=ghc-workload-security

Verify:

kubectl config view --minify

Part 06 — Create the Initial Workload

Create:

baseline-workload.yaml

Add:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: baseline-web
  namespace: ghc-workload-security
  labels:
    app: baseline-web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: baseline-web
  template:
    metadata:
      labels:
        app: baseline-web
    spec:
      containers:
        - name: web
          image: nginx:alpine
          ports:
            - containerPort: 80

Apply:

kubectl apply -f baseline-workload.yaml

Verify:

kubectl get pods

Part 07 — Perform the Initial Security Assessment

Inspect:

kubectl get deployment baseline-web -o yaml

Then:

kubectl describe pod <baseline-pod-name>

Review:

Image

Service Account

Security Context

Resources

Volumes

Environment Variables

Container Ports

Initial Assessment Questions

Ask:

Is runAsNonRoot configured?

Is privilege escalation prevented?

Are Linux capabilities dropped?

Is the root filesystem read-only?

Is seccomp configured?

Are resources defined?

Which ServiceAccount is used?

Is a token automatically mounted?

Is the image version controlled?

Part 08 — Build a Security Assessment Table

Create:

Control	Current State	Desired State
Non-root	Review	Required where supported
Privileged	Review	False
Privilege escalation	Review	False
Capabilities	Review	Minimized
Root filesystem	Writable	Read-only where possible
Seccomp	Review	RuntimeDefault
Resources	Missing	Defined
Service account	Default	Dedicated/minimal
Token mount	Review	Disabled if unnecessary
Image	Mutable tag	Controlled version/digest

This becomes your remediation plan.

Part 09 — Non-Root Execution

One of the most important workload controls is:

Run as Non-Root

Why?

Because application compromise should not automatically provide:

Root-Level Container Access

Security Principle

Application Needs
Only Application Privileges

not:

Application Runs as Root
Because It Is Easier

Part 10 — runAsNonRoot

Kubernetes supports:

securityContext:
  runAsNonRoot: true

This tells Kubernetes that the workload should not run as UID 0.

Important

Setting:

runAsNonRoot: true

does not magically make every image compatible with non-root execution.

The container image must support it.

Part 11 — Image Compatibility

Some images expect:

Root

Privileged Ports

Writable System Paths

When hardening breaks an application, do not automatically remove the control.

Ask:

Can We Use a Non-Root Image?

Can We Change the Port?

Can We Change File Permissions?

Can We Redesign Writable Paths?

Security hardening sometimes reveals poor application assumptions.

Part 12 — Create a Non-Root Training Workload

For this lab, use an image designed to operate without unnecessary root privileges.

Your workload security section should include:

spec:
  securityContext:
    runAsNonRoot: true

Depending on the image, you may also define an appropriate non-zero UID.

Validation

After deployment:

kubectl get pods

Then inspect the workload.

Where supported:

kubectl exec <pod-name> -- id

Expected:

Non-Zero UID

Part 13 — Prevent Privilege Escalation

Another important control is:

allowPrivilegeEscalation: false

Conceptually:

Application Process
      ↓
Cannot Gain Additional Privileges
Through Normal Privilege-Escalation Paths

Container-Level Example

securityContext:
  allowPrivilegeEscalation: false

Security Benefit

This helps reduce opportunities for:

Privilege Escalation

after application compromise.

Part 14 — Privileged Containers

Review:

privileged: true

Privileged containers receive extremely broad access compared with normal containers.

Conceptually:

Normal Container
      ↓
Isolation Controls

versus:

Privileged Container
      ↓
Significantly Reduced Isolation

Security Standard

Application workloads should generally use:

privileged: false

unless there is a documented and reviewed technical requirement.

Part 15 — Linux Capabilities

Linux divides some root privileges into:

Capabilities

Examples include capabilities related to:

Networking

Process Management

System Administration

File Ownership

Kernel Operations

Containers may receive capabilities they do not need.

Better Security Model

Instead of:

Give Broad Privilege

use:

Drop Everything
      ↓
Add Only What Is Required

Part 16 — Drop Capabilities

A strong starting point is:

securityContext:
  capabilities:
    drop:
      - ALL

This removes available Linux capabilities from the container.

Important

Applications requiring specific capabilities may need carefully reviewed exceptions.

The objective is:

Minimum Required Capabilities

Part 17 — Capability Review

For every application ask:

Which Capabilities Are Required?

Why?

Can the Application Work Without Them?

What Happens If the Container Is Compromised?

Do not add capabilities simply to make an application start without understanding why.

Part 18 — Read-Only Root Filesystem

Containers often do not need to modify their root filesystem after startup.

Use:

securityContext:
  readOnlyRootFilesystem: true

where compatible.

Security Benefit

This can make it more difficult for compromised processes to:

Modify Application Files

Replace Binaries

Drop Persistent Tools

Alter Configuration

Part 19 — Writable Paths

Some applications legitimately need writable directories.

The better architecture is often:

Read-Only Root Filesystem
        +
Explicit Writable Volume

rather than:

Entire Container Filesystem Writable

Example Architecture

Container Root
     ↓
Read Only

/tmp
     ↓
Writable Temporary Volume

Part 20 — Temporary Writable Storage

Where appropriate, Kubernetes can provide temporary storage using:

emptyDir

Conceptually:

volumes:
  - name: tmp
    emptyDir: {}

and:

volumeMounts:
  - name: tmp
    mountPath: /tmp

This provides an explicitly writable location without requiring the entire root filesystem to remain writable.

Part 21 — Seccomp

Seccomp can restrict the Linux system calls available to processes.

A common Kubernetes hardening configuration is:

securityContext:
  seccompProfile:
    type: RuntimeDefault

Security Model

Application
   ↓
System Calls
   ↓
Seccomp Policy
   ↓
Allowed / Restricted

Why Seccomp Matters

A compromised application should not automatically have unrestricted access to every available kernel interface.

Seccomp contributes another isolation layer.

Part 22 — Hardened Security Context

A hardened container may conceptually use:

securityContext:
  allowPrivilegeEscalation: false
  privileged: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

At Pod level:

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault

Hardening Stack

Non-Root
   +
No Privilege Escalation
   +
Not Privileged
   +
Capabilities Dropped
   +
Read-Only Root Filesystem
   +
Seccomp

Part 23 — Service Account Security

Every Pod operates with a Kubernetes ServiceAccount identity.

If none is explicitly configured, the Pod typically uses the namespace’s:

default

ServiceAccount.

Security Question

Ask:

Does This Application
Need Kubernetes API Access?

Many applications do not.

Part 24 — Create a Dedicated Service Account

Create:

kubectl create serviceaccount workload-app

Verify:

kubectl get serviceaccount workload-app

Then configure:

spec:
  serviceAccountName: workload-app

Why Dedicated Identity?

It provides:

Clear Workload Identity

Better RBAC Control

Better Auditability

Reduced Shared Identity

Part 25 — Disable Unnecessary Token Mounting

If the workload does not require Kubernetes API access, consider:

automountServiceAccountToken: false

Security Benefit

This reduces unnecessary credential exposure inside the container.

Conceptually:

Application Does Not Need API
      ↓
Do Not Provide API Credential

Part 26 — Validate Token Configuration

Inspect:

kubectl describe pod <pod-name>

and the Pod YAML.

Determine whether Kubernetes API credentials are mounted.

Security Principle

No Requirement
      ↓
No Credential

Part 27 — RBAC Review

If the application does require Kubernetes API access, grant only required permissions.

Use:

kubectl auth can-i --list --as=system:serviceaccount:ghc-workload-security:workload-app

Review:

Secrets

Pods

Deployments

Jobs

ConfigMaps

Cluster Resources

Avoid

cluster-admin

for ordinary applications.

Part 28 — Secrets Security

Applications frequently need credentials such as:

Database Password

API Token

TLS Material

Application Secret

Avoid:

Hardcoded Secret in Image

and:

Hardcoded Secret in Git

Better Model

Secret Source
   ↓
Controlled Delivery
   ↓
Application

Part 29 — Kubernetes Secrets

Kubernetes Secrets provide a native mechanism for referencing sensitive values.

But remember:

Base64
      ≠
Encryption

Secret security still depends on:

RBAC

Encryption at Rest

Access Controls

Rotation

External Secret Management

Logging Discipline

Part 30 — Secret Exposure Review

Look for:

Secrets in Environment Variables

Secrets in Command Arguments

Secrets in Logs

Secrets in ConfigMaps

Secrets Embedded in Images

Secrets Stored in Git

Security Principle

Reduce:

Secret Copies

and:

Secret Exposure Locations

Part 31 — Secret Rotation

A mature design supports:

Credential Created
      ↓
Securely Delivered
      ↓
Used
      ↓
Rotated
      ↓
Old Credential Revoked

Incident response becomes much easier when credentials can be rotated predictably.

Part 32 — Resource Requests and Limits

Workload security also includes availability.

Define:

CPU Requests

Memory Requests

CPU Limits

Memory Limits

Example:

resources:
  requests:
    cpu: "100m"
    memory: "64Mi"
  limits:
    cpu: "250m"
    memory: "128Mi"

Why Resources Are Security Relevant

Without controls, a workload could contribute to:

Resource Exhaustion

Node Pressure

Application Instability

Denial of Service

Part 33 — Requests vs Limits

Think:

Request
=
What the scheduler should reserve

and:

Limit
=
Maximum controlled resource usage

Exact behavior differs between CPU and memory, so administrators should understand the runtime implications.

Part 34 — Container Image Security

Workload security starts before runtime.

Review:

Image Source

Image Tag

Image Digest

Base Image

Known Vulnerabilities

Image Size

Included Tools

Image User

Better Image Model

Trusted Source
      ↓
Minimal Image
      ↓
Vulnerability Scanning
      ↓
Controlled Version
      ↓
Deployment

Part 35 — Avoid Uncontrolled Mutable Tags

Avoid relying on:

latest

for controlled production deployment.

Why?

Deployment Manifest
      ↓
Same Tag
      ↓
Image Content Changes

This reduces predictability.

Better Approach

Use:

Controlled Version Tags

or stronger immutable references where required by your environment.

Part 36 — Image Digests

An image digest provides an immutable content reference.

Conceptually:

Repository
   ↓
Image Digest
   ↓
Exact Image Content

This strengthens:

Repeatability

Traceability

Supply-Chain Control

Part 37 — Minimal Images

Large images may contain unnecessary:

Shells

Package Managers

Utilities

Libraries

Reducing unnecessary software can reduce:

Attack Surface

Principle

If the Application
Does Not Need It,
Do Not Include It.

Part 38 — Image Vulnerability Scanning

Before deployment:

Image
  ↓
Vulnerability Scan
  ↓
Risk Evaluation
  ↓
Approve / Remediate

Scanning should consider:

Severity

Exploitability

Runtime Reachability

Application Context

Available Fix

Do not treat every vulnerability as equal.

Part 39 — Host Namespace Security

Review:

hostNetwork

hostPID

hostIPC

These features allow workloads to share aspects of the node environment.

Security Risk

Container Compromise
      +
Host Namespace Access
      ↓
Potential Increased Impact

Ordinary applications should not use these without a valid reason.

Part 40 — hostPath Security

Review:

hostPath

volumes carefully.

A writable hostPath can expose host filesystem locations to a container.

Questions

Which Path?

Read-Only?

Why Required?

Could Another Volume Type Work?

What Happens After Container Compromise?

Part 41 — Workload Volume Review

For every volume ask:

What Data?

Who Can Access It?

Read or Write?

Persistent?

Shared?

Sensitive?

Host-Backed?

Part 42 — Environment Variables

Review environment variables for:

Secrets

Internal Endpoints

Cloud Credentials

Debug Flags

Sensitive Configuration

Avoid unnecessary sensitive values in locations easily exposed through:

Process Inspection

Debug Output

Support Bundles

Logs

Part 43 — Probes and Availability

Configure appropriate:

Startup Probes

Readiness Probes

Liveness Probes

These are primarily reliability controls, but workload resilience contributes to overall security and availability.

Important

Poorly configured probes can create:

Restart Loops

Unavailable Applications

Security hardening must not ignore operational reliability.

Part 44 — Pod Security Standards

Kubernetes Pod Security Standards define three conceptual policy levels:

Privileged

Baseline

Restricted

Privileged

Provides broad permissions and minimal restrictions.

Appropriate only for workloads that genuinely require elevated capabilities and are carefully controlled.

Baseline

Attempts to prevent common privilege-escalation risks while remaining broadly compatible.

Restricted

Represents a stronger workload-hardening profile.

Conceptually:

Privileged
    ↓
Baseline
    ↓
Restricted

with security increasing as restrictions increase.

Part 45 — Restricted Workload Thinking

A restricted-style workload generally aims for controls such as:

Non-Root

No Privilege Escalation

Restricted Capabilities

Seccomp

No Privileged Container

Limited Host Access

The exact applicable requirements should be validated against your Kubernetes environment and current organizational standard.

Part 46 — Namespace-Level Pod Security

Organizations can apply Pod Security Admission controls through namespace configuration.

Before changing namespace security settings, understand:

Existing Workloads

Required Policy Level

Enforcement Impact

Warnings

Audit Requirements

Rollout Model

Understand
   ↓
Audit
   ↓
Warn
   ↓
Remediate
   ↓
Enforce

Part 47 — Admission Policy Integration

Your previous Kyverno and Gatekeeper labs now become relevant.

Instead of telling every developer:

Please Remember
runAsNonRoot

you can enforce:

Workloads Must
Run as Non-Root

Security Evolution

Documentation
      ↓
Recommendation
      ↓
Automated Validation
      ↓
Enforcement

Part 48 — Network Security Integration

A hardened workload should also have appropriate communication restrictions.

Ask:

Who Can Reach It?

Where Can It Connect?

Does It Need Internet Access?

Can It Reach Sensitive Services?

Use your NetworkPolicy knowledge.

Part 49 — Runtime Security Integration

Even a hardened workload can still be compromised.

Therefore:

Workload Hardening
      +
Runtime Detection

provides stronger protection.

Example

Non-Root
      ↓
Reduces Impact

Runtime Detection
      ↓
Detects Unexpected Shell

Part 50 — Build the Hardened Workload

Now combine the controls.

Create:

hardened-workload.yaml

A representative structure is:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: workload-app
  namespace: ghc-workload-security
automountServiceAccountToken: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hardened-web
  namespace: ghc-workload-security
  labels:
    app: hardened-web
    owner: platform-security
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hardened-web
  template:
    metadata:
      labels:
        app: hardened-web
    spec:
      serviceAccountName: workload-app
      automountServiceAccountToken: false

      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

      containers:
        - name: web
          image: <approved-non-root-image>:<controlled-version>

          ports:
            - containerPort: 8080

          securityContext:
            privileged: false
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL

          resources:
            requests:
              cpu: "100m"
              memory: "64Mi"
            limits:
              cpu: "250m"
              memory: "128Mi"

          volumeMounts:
            - name: tmp
              mountPath: /tmp

      volumes:
        - name: tmp
          emptyDir: {}

Important

The image placeholder is intentional.

Choose a known training image that:

Supports Non-Root Execution

Uses the Configured Port

Works with Read-Only Root Filesystem

Do not blindly copy a root-dependent image into this hardened configuration and disable controls when it fails.

Part 51 — Apply the Hardened Workload

After selecting a compatible training image:

kubectl apply -f hardened-workload.yaml

Watch:

kubectl get pods -w

If it starts successfully, continue with validation.

If it fails:

Do Not Immediately Remove Security Controls

Investigate the cause.

Part 52 — Troubleshoot Hardened Workload Startup

Use:

kubectl describe pod <hardened-pod-name>

Then:

kubectl logs <hardened-pod-name>

Check:

Image Compatibility

Filesystem Writes

UID Requirements

Port Binding

Volume Permissions

Security Context

Troubleshooting Workflow

Pod Fails
   ↓
Events
   ↓
Logs
   ↓
Security Configuration
   ↓
Application Requirement
   ↓
Secure Remediation

Part 53 — Validate Non-Root

Where supported:

kubectl exec <hardened-pod-name> -- id

Confirm:

UID != 0

Record the evidence.

Part 54 — Validate Security Context

Inspect:

kubectl get pod <hardened-pod-name> -o yaml

Confirm:

runAsNonRoot: true

allowPrivilegeEscalation: false

privileged: false

readOnlyRootFilesystem: true

capabilities:
  drop:
  - ALL

seccompProfile:
  type: RuntimeDefault

Part 55 — Validate Service Account

Check:

kubectl get pod <hardened-pod-name> -o jsonpath='{.spec.serviceAccountName}'

Expected:

workload-app

Then:

kubectl get serviceaccount workload-app -o yaml

Part 56 — Validate API Permissions

Where authorized:

kubectl auth can-i --list --as=system:serviceaccount:ghc-workload-security:workload-app

Verify the workload has no unnecessary application permissions.

Desired Principle

Application Identity
      ↓
Minimum Required Access

Part 57 — Validate Token Mounting

Inspect:

kubectl describe pod <hardened-pod-name>

Confirm the application is not unnecessarily receiving a Kubernetes API credential.

Part 58 — Validate Resources

Run:

kubectl describe pod <hardened-pod-name>

Confirm:

Requests

Limits

are present.

Part 59 — Validate Writable Filesystem Behavior

With an approved lab image, test only harmless paths.

Attempting to write to a protected root-filesystem location should fail when the filesystem is read-only.

The explicitly writable path such as:

/tmp

should behave according to the mounted temporary volume.

Security Lesson

You have changed:

Everything Writable

into:

Only Required Locations Writable

Part 60 — Compare Before and After

Create:

Security Control	Baseline	Hardened
Non-root	Not guaranteed	Required
Privileged	Not explicitly controlled	False
Privilege escalation	Not restricted	False
Capabilities	Default	Dropped
Root filesystem	Writable	Read-only
Seccomp	Review	RuntimeDefault
Service account	Default	Dedicated
Token	Potentially mounted	Disabled if unnecessary
Resources	Missing	Defined
Image	Basic tag	Controlled image/version

Part 61 — Attack Path Comparison

Before:

Application Compromise
        ↓
Broad Container Privileges
        ↓
Credential Access
        ↓
Network Access
        ↓
Potential Expansion

After:

Application Compromise
        ↓
Non-Root
        ↓
No Privilege Escalation
        ↓
Minimal Capabilities
        ↓
Read-Only Filesystem
        ↓
Minimal Identity
        ↓
Restricted Network
        ↓
Reduced Blast Radius

Part 62 — Security Finding 01

Document the original workload.

Finding:
Application Container Lacks
Workload Hardening Controls

Affected Resource:
baseline-web

Namespace:
ghc-workload-security

Observation:
The workload does not explicitly implement
several recommended container security controls.

Threat Scenario:
If the application is compromised,
the attacker may inherit broader runtime
capabilities than required.

Risk:
High

Recommendation:
Implement a workload security baseline
including non-root execution,
privilege restrictions,
capability reduction,
seccomp and filesystem hardening.

Part 63 — Security Finding 02

Finding:
Application Uses Default Service Account

Observation:
The application does not use a dedicated
workload identity.

Risk:
Medium

Recommendation:
Create a dedicated ServiceAccount,
grant only required permissions,
and disable automatic token mounting
when Kubernetes API access is unnecessary.

Part 64 — Security Finding 03

Finding:
Container Resource Controls Are Missing

Observation:
CPU and memory requests and limits
are not explicitly configured.

Threat Scenario:
Unexpected resource consumption could
affect workload or node availability.

Recommendation:
Define resource requests and limits
based on application performance requirements.

Part 65 — Professional Finding Template

Use:

Finding:

Affected Resource:

Namespace:

Observed Configuration:

Expected Configuration:

Evidence:

Threat Scenario:

Business Impact:

Risk:

Recommendation:

Remediation:

Validation:

Part 66 — Workload Security Review Framework

For every workload review:

01 Image

02 User

03 Privilege

04 Capabilities

05 Filesystem

06 Seccomp

07 Service Account

08 RBAC

09 Secrets

10 Volumes

11 Network

12 Resources

13 Logging

14 Runtime Detection

Part 67 — Image Review Questions

Ask:

Where Did the Image Come From?

Is the Registry Trusted?

Is the Image Scanned?

Does It Run as Root?

Is the Version Controlled?

Is the Image Minimal?

Are Unnecessary Tools Included?

Part 68 — Identity Review Questions

Ask:

Which ServiceAccount?

Does It Need API Access?

What RBAC Permissions?

Is Token Mounting Required?

Is Cloud Workload Identity Used?

Could Permissions Be Reduced?

Part 69 — Privilege Review Questions

Ask:

Is privileged Enabled?

Can Privilege Escalation Occur?

Which Capabilities Exist?

Is Root Required?

Are Host Namespaces Used?

Are Host Volumes Used?

Part 70 — Filesystem Review Questions

Ask:

Is Root Filesystem Writable?

Which Paths Need Write Access?

Can Explicit Volumes Be Used?

Are Sensitive Volumes Mounted?

Are Host Paths Exposed?

Part 71 — Network Review Questions

Ask:

Who Can Reach the Workload?

Where Can It Connect?

Is Default-Deny Used?

Does It Need Internet Egress?

Can It Reach Sensitive Internal Services?

Part 72 — Secret Review Questions

Ask:

Which Secrets Are Available?

Does the Application Need Them?

How Are They Delivered?

Who Can Read Them?

Are They Rotated?

Could Logs Expose Them?

Part 73 — Runtime Review Questions

Ask:

Is Runtime Monitoring Enabled?

Can Unexpected Shells Be Detected?

Can Suspicious Processes Be Detected?

Can Sensitive File Access Be Detected?

Can Network Anomalies Be Investigated?

Part 74 — Policy Enforcement

Once your hardened baseline is validated, automate it.

Use technologies from earlier labs:

Pod Security Admission

Kyverno

OPA Gatekeeper

Possible policies:

Require Non-Root

Block Privileged

Block Privilege Escalation

Require Seccomp

Restrict Capabilities

Require Resource Controls

Restrict Registries

Part 75 — Why Automation Matters

Manual review:

100 Workloads
      ↓
100 Security Reviews

Automated guardrails:

Security Standard
      ↓
Policy-as-Code
      ↓
Every Deployment Evaluated

Part 76 — Workload Security Baseline

Create an organizational baseline:

All Standard Application Workloads:

Must run non-root

Must not run privileged

Must prevent privilege escalation

Must minimize capabilities

Must use approved seccomp configuration

Should use read-only root filesystem where compatible

Must use controlled images

Must define resources

Must use least-privileged identity

Must follow network segmentation requirements

Part 77 — Exception Management

Some workloads may require elevated functionality.

Examples can include certain:

Networking Components

Storage Components

Security Agents

Node-Level Utilities

Do not weaken the baseline globally.

Use:

Specific Exception

Documented Requirement

Risk Assessment

Compensating Controls

Approval

Review Date

Part 78 — Workload Exception Template

Workload:

Namespace:

Security Control:

Requested Exception:

Technical Reason:

Risk:

Compensating Controls:

Owner:

Approver:

Expiration:

Review Date:

Part 79 — Security Challenge 01

You discover:

privileged: true

Ask:

Why Is It Required?

Can It Be Removed?

Can a Specific Capability Replace It?

Can the Architecture Be Changed?

Document your recommendation.

Part 80 — Security Challenge 02

You discover:

cluster-admin

assigned to the workload ServiceAccount.

Determine:

Actual API Requirement

Minimum Resources

Required Verbs

Namespace Scope

Design a least-privilege replacement.

Part 81 — Security Challenge 03

You discover:

hostPath: /

mounted writable.

Assess:

Host Exposure

Potential Impact

Business Requirement

Alternative Storage

Required Containment

Treat this as a high-priority security concern.

Part 82 — Security Challenge 04

You discover:

image: application:latest

Design remediation using:

Controlled Image Version

Trusted Registry

Scanning

Image Verification

Deployment Approval

Part 83 — Security Challenge 05

The application requires writing to:

/tmp

but you want:

readOnlyRootFilesystem: true

Design:

Read-Only Root
      +
Writable emptyDir for /tmp

instead of disabling filesystem protection entirely.

Part 84 — Security Challenge 06

The application does not call the Kubernetes API.

Determine whether:

automountServiceAccountToken: false

is appropriate.

Validate application functionality afterward.

Part 85 — Security Challenge 07

A hardened workload stops working after:

capabilities:
  drop:
    - ALL

Do not simply restore all capabilities.

Determine:

Which Specific Capability Is Required?

Why?

Can Application Design Remove the Requirement?

Then add only the minimum required capability if justified.

Part 86 — Security Challenge 08

A workload cannot run with:

runAsNonRoot: true

Investigate:

Image USER

File Ownership

Port Requirements

Startup Script

Writable Paths

Determine whether the image should be rebuilt.

Part 87 — Defense in Depth Architecture

Your complete Kubernetes security architecture now looks like:

Trusted Source
      ↓
Secure Build
      ↓
Image Scanning
      ↓
Trusted Registry
      ↓
Admission Policy
      ↓
Hardened Workload
      ↓
RBAC
      ↓
NetworkPolicy
      ↓
Runtime Detection
      ↓
Central Logging
      ↓
Incident Response

No single control is expected to stop every threat.

Part 88 — Kubernetes Security Layers

You have now worked across:

IDENTITY
   ↓
RBAC

CONFIGURATION
   ↓
Kyverno / Gatekeeper

NETWORK
   ↓
NetworkPolicy

WORKLOAD
   ↓
SecurityContext

RUNTIME
   ↓
Behavioral Detection

RESPONSE
   ↓
Investigation and Containment

Part 89 — Evidence Collection

Capture:

Baseline Deployment

Baseline Security Assessment

Hardened Deployment

Non-Root Validation

Privilege Configuration

Capabilities

Filesystem Configuration

Seccomp Configuration

ServiceAccount

Token Configuration

RBAC Review

Resource Controls

Before/After Comparison

Security Findings

Lab Evidence Template

Lab:
Kubernetes Workload Security

Date:

Cluster:

Namespace:

Baseline Workload:

Baseline Risks:

Hardened Workload:

Non-Root:
Pass / Fail

Privilege Escalation:
Pass / Fail

Capabilities:
Pass / Fail

Read-Only Filesystem:
Pass / Fail

Seccomp:
Pass / Fail

Service Account:
Pass / Fail

Token Mount:
Pass / Fail

Resources:
Pass / Fail

Image Review:
Pass / Fail

Security Findings:

Remediation:

Validation:

Part 90 — Workload Security Scorecard

Score the workload:

Control	Pass	Fail	N/A
Non-root	☐	☐	☐
Privileged disabled	☐	☐	☐
Privilege escalation disabled	☐	☐	☐
Capabilities minimized	☐	☐	☐
Read-only root filesystem	☐	☐	☐
Seccomp	☐	☐	☐
Dedicated ServiceAccount	☐	☐	☐
Least-privilege RBAC	☐	☐	☐
Token mounting controlled	☐	☐	☐
Secrets protected	☐	☐	☐
Resource controls	☐	☐	☐
Image controlled	☐	☐	☐
Network segmentation	☐	☐	☐
Runtime monitoring	☐	☐	☐

Part 91 — Remediation Prioritization

Prioritize findings based on:

Exploitability

Privilege

Internet Exposure

Data Sensitivity

Identity Permissions

Network Reachability

Business Criticality

Example Priority

Privileged + Internet-Facing
        ↓
Critical Attention

Missing Ownership Label
        ↓
Governance Issue

Both matter, but not equally.

Part 92 — Cleanup

Preserve your evidence first.

Then:

kubectl delete namespace ghc-workload-security

Verify:

kubectl get namespace ghc-workload-security

Restore your normal namespace:

kubectl config set-context --current --namespace=default

Lab Completion Checklist

Assessment

Container Hardening

Implemented non-root execution
Disabled privileged mode
Disabled privilege escalation
Dropped unnecessary capabilities
Implemented read-only root filesystem
Configured explicit writable storage
Used seccomp protection

Identity

Created dedicated ServiceAccount
Reviewed RBAC
Applied least privilege
Disabled unnecessary token mounting

Secrets

Reviewed secret references
Avoided hardcoded credentials
Understood base64 vs encryption
Considered rotation

Availability

Configured CPU requests
Configured memory requests
Configured CPU limits
Configured memory limits

Supply Chain

Kubernetes Security

Understood Pod Security Standards
Understood Restricted-style hardening
Connected hardening with admission policy
Connected hardening with NetworkPolicy
Connected hardening with runtime security

Professional Skills

Skills You Practiced

You have now worked with:

Kubernetes Workload Security

Container Hardening

Security Contexts

Non-Root Execution

Privilege Management

Linux Capabilities

Filesystem Security

Seccomp

Service Accounts

RBAC

Secrets

Resource Controls

Image Security

Pod Security Standards

Career Connection

These skills are highly relevant for:

Kubernetes Security Engineer

Cloud Security Engineer

DevSecOps Engineer

Platform Security Engineer

Container Security Engineer

Cloud Security Architect

Security Consultant

Kubernetes Administrator

Interview Questions

What is Kubernetes workload security?
What is a securityContext?
What is the difference between Pod-level and container-level securityContext?
Why should containers run as non-root?
What does runAsNonRoot do?
Why might an image fail after enabling non-root execution?
What does allowPrivilegeEscalation control?
What is a privileged container?
Why are privileged containers dangerous?
What are Linux capabilities?
Why would you drop all capabilities?
When might a capability need to be added back?
What does readOnlyRootFilesystem do?
Why is a read-only root filesystem useful?
How can an application write temporary data with a read-only root filesystem?
What is seccomp?
What does RuntimeDefault mean conceptually?
Why are host namespaces security-sensitive?
What is hostPath?
Why can writable hostPath volumes be dangerous?
What is a Kubernetes ServiceAccount?
Why should applications use dedicated ServiceAccounts?
Why disable automatic ServiceAccount token mounting?
When does an application need Kubernetes API access?
How does RBAC affect workload security?
Why should workloads not receive cluster-admin?
Why are Kubernetes Secrets not automatically secure simply because values appear base64 encoded?
How should secrets be protected?
Why is secret rotation important?
Why are resource requests security relevant?
Why are resource limits security relevant?
What security risk can uncontrolled resource consumption create?
Why should container images come from trusted registries?
Why can latest be problematic?
What is an image digest?
Why are minimal container images useful?
What is container vulnerability scanning?
What are Pod Security Standards?
What are the three Pod Security Standards levels?
What does Restricted aim to accomplish?
How can Kyverno enforce workload security?
How can Gatekeeper enforce workload security?
How does NetworkPolicy complement workload hardening?
How does runtime monitoring complement workload hardening?
What is defense in depth?
How would you assess a Kubernetes workload?
How would you prioritize workload-security findings?
How should workload exceptions be handled?
What evidence would you collect during a workload-security assessment?
How would you build an enterprise Kubernetes workload-security baseline?

Practical Readiness Milestone

You should now be able to receive:

Deployment Manifest

and review:

IMAGE
   ↓
IDENTITY
   ↓
PRIVILEGE
   ↓
CAPABILITIES
   ↓
FILESYSTEM
   ↓
SECCOMP
   ↓
SECRETS
   ↓
VOLUMES
   ↓
RESOURCES
   ↓
NETWORK
   ↓
RUNTIME

Then transform:

Functional Workload

into:

Functional
      +
Hardened
      +
Observable
      +
Governed
Workload

Security Readiness Milestone

You should be able to ask:

If this application
is compromised today...

then determine:

What User Does It Run As?

Can It Escalate?

What Capabilities Does It Have?

What Can It Write?

What Credentials Can It Access?

What Kubernetes Permissions Exist?

What Network Destinations Can It Reach?

Can Suspicious Behavior Be Detected?

This is the core workload-security mindset.

Final Lab Mental Model

Remember:

ASSUME APPLICATION COMPROMISE
        ↓
MINIMIZE PRIVILEGE
        ↓
MINIMIZE IDENTITY
        ↓
MINIMIZE FILESYSTEM ACCESS
        ↓
MINIMIZE CREDENTIALS
        ↓
MINIMIZE NETWORK ACCESS
        ↓
MONITOR BEHAVIOR
        ↓
REDUCE BLAST RADIUS

The goal is not to make compromise theoretically impossible.

The goal is to ensure:

One Compromised Application
Does Not Automatically Become
a Compromised Kubernetes Environment.

Lab Outcome

Before this lab:

You knew how to deploy
and operate Kubernetes workloads.

After this lab:

You assessed insecure workloads,

implemented non-root execution,

restricted privileges,

dropped capabilities,

protected filesystems,

applied seccomp,

secured workload identity,

reduced credential exposure,

implemented resource controls,

reviewed image security,

and validated a hardened workload.

You have moved from:

Running Kubernetes Applications

to:

Running Security-Hardened
Kubernetes Workloads.

Kubernetes Labs Complete

You have now completed the Kubernetes security lab sequence:

Lab 01 — Kubernetes Fundamentals
        ↓
Resource Understanding

Lab 02 — Kubernetes RBAC
        ↓
Identity Security

Lab 03 — Kyverno
        ↓
Policy-as-Code

Lab 04 — Network Policies
        ↓
Network Segmentation

Lab 05 — OPA Gatekeeper
        ↓
Admission Governance

Lab 06 — Runtime Security
        ↓
Threat Detection

Lab 07 — Workload Security
        ↓
Workload Hardening

Together, these labs form:

IDENTITY
   +
POLICY
   +
NETWORK
   +
WORKLOAD
   +
RUNTIME

What’s Next?

➡️ Runbook 01 — Kubernetes Compliance Assessment

You have learned how individual Kubernetes security controls work.

Now you will move from:

Implementing Individual Controls

to:

Assessing an Entire Kubernetes
Environment Systematically.

The runbook will provide a repeatable professional workflow for reviewing:

Cluster Security

Identity and RBAC

Workload Security

Network Segmentation

Admission Policies

Secrets

Logging

Runtime Security

Security Baselines

Compliance Evidence

Findings

Remediation

The learning progression now becomes:

CERTIFICATIONS
      ↓
Build Knowledge

LABS
      ↓
Build Practical Skills

RUNBOOKS
      ↓
Build Repeatable
Professional Security Operations

You are now ready to move from Kubernetes security practitioner to performing structured Kubernetes security assessments.