Lab 09: Container & Kubernetes Security

Time: 50 minutes | Level: Architect | Docker: docker run -it --rm zchencow/innozverse-cybersec:latest bash

Objectives

  • Architect container security from image to runtime

  • Understand Kubernetes admission controllers and Pod Security Standards

  • Design network policies and secrets management

  • Build a Kubernetes YAML security policy validator


Step 1: Container Security Architecture Layers

┌─────────────────────────────────────────────────────────┐
│                  CONTAINER SECURITY LAYERS               │
│                                                         │
│  1. BUILD TIME          2. DEPLOY TIME      3. RUNTIME  │
│  ┌────────────┐        ┌─────────────┐    ┌──────────┐ │
│  │Image scan  │        │Admission    │    │Falco     │ │
│  │Base image  │   →    │Controllers  │ →  │Runtime   │ │
│  │SBOM gen    │        │Pod Security │    │Detection │ │
│  │Secret scan │        │Standards    │    │Network   │ │
│  │Dockerfile  │        │Network      │    │Policies  │ │
│  │lint        │        │Policies     │    │          │ │
│  └────────────┘        └─────────────┘    └──────────┘ │
└─────────────────────────────────────────────────────────┘

Step 2: Image Security

Base image selection:

  • Use minimal base images: distroless, alpine, scratch

  • Never use latest tag — always pin to digest: nginx@sha256:abc...

  • Build from official images; verify provenance (Sigstore/Cosign)

Dockerfile security:

Image scanning tools:

Tool
Type
Integration

Trivy

Open source

CI/CD, registry

Snyk

Commercial

IDE, CI/CD

Grype

Open source

CI/CD

AWS ECR

Cloud-native

Registry scan

Prisma Cloud

Commercial

Full lifecycle


Step 3: Pod Security Standards

Three enforcement levels:

Level
Description
Who Should Use

Privileged

No restrictions

System namespaces (kube-system)

Baseline

Minimum restrictions, blocks known privesc

Most workloads

Restricted

Hardened, follows security best practices

Security-sensitive workloads

Restricted policy enforces:

  • runAsNonRoot: true

  • allowPrivilegeEscalation: false

  • readOnlyRootFilesystem: true

  • capabilities: drop: [ALL]

  • seccompProfile: RuntimeDefault

  • No hostPath volumes

Apply PSS to namespace:


Step 4: Kubernetes Security Policy Validator

📸 Verified Output:


Step 5: Admission Controllers

Types of admission controllers:

Controller
Type
Use Case

Pod Security Admission

Built-in

Enforce PSS levels

OPA/Gatekeeper

Webhook

Custom Rego policies

Kyverno

Webhook

YAML-native policies

ImagePolicyWebhook

Built-in

Require signed images

ValidatingWebhookConfiguration

Webhook

Custom validation

Kyverno policy example:


Step 6: Network Policies

Default deny all + explicit allow:

💡 CNI plugins that support NetworkPolicy: Calico, Cilium, Weave. The default Kubernetes networking (kubenet) does NOT enforce NetworkPolicy — you must install a compliant CNI.


Step 7: Secrets Management

Kubernetes secrets problems:

  • Stored base64-encoded in etcd (not encrypted by default)

  • Can be exposed via kubectl get secret to anyone with RBAC access

  • Appear in environment variables (visible in /proc)

Best practices:

  1. Enable etcd encryption at rest (EncryptionConfiguration)

  2. Use external secrets manager (HashiCorp Vault, AWS Secrets Manager)

  3. Inject secrets at runtime via CSI driver (no env vars)

  4. RBAC: least privilege on secrets — workload SA only reads its own

Vault + Kubernetes (CSI driver):


Step 8: Capstone — Kubernetes Security Architecture

Scenario: Production Kubernetes cluster for PCI DSS workloads


Summary

Layer
Control
Implementation

Image

Scan + sign

Trivy, Cosign, ECR

Admission

Policy enforcement

Kyverno, Gatekeeper, PSA

Pod security

Hardened context

PSS Restricted, drop capabilities

Network

Micro-segmentation

NetworkPolicy + Istio mTLS

Secrets

External vault

HashiCorp Vault CSI driver

Runtime

Threat detection

Falco rules + SIEM alerting

Last updated