PS Product SecurityKnowledge Base

🐳☸️ Implementing DevSecOps with Docker and Kubernetes — Modernization Map

Intro: Books built around Docker and Kubernetes are still useful when they teach packaging, least privilege, review loops, monitoring, and attack-surface awareness. What changes fastest is the platform detail: admission control, service account defaults, image signing, and controller names. This page keeps the enduring lessons and rewrites the parts that age quickly.

What this page includes

  • durable Docker and Kubernetes security lessons;
  • historical notes that should now be treated as legacy context;
  • a modernization map for 2026 platform defaults and safer patterns;
  • rollout advice for teams translating older labs into current clusters.

The durable lessons worth keeping

  • image build paths are part of the attack surface;
  • cluster identity and authorization matter more than one hardening flag;
  • secrets and service accounts are common escalation paths;
  • monitoring and runtime visibility are necessary because pre-release checks never catch everything;
  • older hands-on labs remain educational if they are clearly marked as lab-only and translated before reuse in real environments.

Historical versus current Kubernetes defaults

Historical example Why it was common Current interpretation
PodSecurityPolicy examples PSP used to be the built-in pod control surface use Pod Security Admission plus Kyverno / Gatekeeper where needed
long-lived service account token assumptions older clusters auto-created legacy tokens prefer projected, rotating tokens and automountServiceAccountToken: false by default
privileged troubleshooting as routine easier to get labs working make exceptions explicit, rare, and namespace-scoped
static kubeconfig copy habits operational convenience prefer controlled access paths, workload identity, and reduced admin sprawl
Docker Content Trust-era advice image signing pattern of its time use current sigstore / cosign or equivalent modern signing and verification workflows

Docker-side modernization

Still right

  • keep images small and purposeful;
  • avoid baking build tools into production images;
  • avoid root where practical;
  • scan images before release;
  • treat registry trust as a security concern.

Update this part

  • do not rely on deprecated or retired signing guidance;
  • avoid treating daemon trust as a solved problem just because a scan passed;
  • use reproducible builds, provenance, SBOM, and verification where your platform supports them.

Kubernetes-side modernization

1) Service account posture

Old clusters often normalized mounted static tokens. Current safer pattern:

  • disable automatic token mounting unless needed;
  • prefer projected tokens and workload identity;
  • bind RBAC narrowly to namespace and verb.

2) Pod security posture

Current baseline expectation:

  • runAsNonRoot: true where practical;
  • allowPrivilegeEscalation: false;
  • seccompProfile: RuntimeDefault;
  • drop capabilities;
  • avoid host namespaces and hostPath except for tightly controlled system workloads.

3) Admission and policy

Use:

  • Pod Security Admission for baseline enforcement;
  • Kyverno or Gatekeeper for organization-specific controls;
  • image policy and registry rules where available.

4) API and kubelet exposure

Keep explicit review for:

  • API server reachability;
  • exec and secret-read permissions;
  • kubelet exposure and authn/authz configuration;
  • etcd access and encryption.

A minimal current workload example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  template:
    spec:
      automountServiceAccountToken: false
      containers:
        - name: api
          image: ghcr.io/example/orders-api:1.4.2
          securityContext:
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
            seccompProfile:
              type: RuntimeDefault

Runtime and monitoring modernization

Older books often focus on deployment first and monitoring later. In current practice, connect them earlier.

High-value runtime layers:

  • audit logs;
  • admission events;
  • registry and signature verification outcomes;
  • runtime detections for shell, exec, drift, or sensitive file access;
  • image and workload posture findings tied back to owners.

How to use older hands-on labs safely

Keep them for:

  • learning cluster internals;
  • understanding attack surface and privilege transitions;
  • exploring why certain defaults are dangerous.

Do not copy directly into current production guidance:

  • historical kubeadm flags without checking current docs;
  • PSP examples as live policy strategy;
  • blanket privileged containers for convenience;
  • static long-lived service account token patterns;
  • retired image-signing workflows.

A translation checklist for old Docker/Kubernetes examples

  • Does this example assume PSP still exists?
  • Does it mount or rely on long-lived service account tokens?
  • Does it require privileged containers only because it is a lab?
  • Does it assume old image signing or registry patterns?
  • Does it treat API access or kubelet exposure as a side note instead of a first-class review point?

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.