# 🐳☸️ 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

```yaml
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?

## Cross-links

* [Dockerfile Security Best Practices](/cloud-kubernetes-and-infrastructure-security/index-1/dockerfile-security-best-practices.md)
* [Kubernetes Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-hardening.md)
* [Kubernetes API Access Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-api-access-hardening.md)
* [Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md)
* [Runtime Detection Stack — Falco, Tetragon, and Cloud Signals](/attack-paths-testing-detection-and-hardening/index/runtime-detection-stack-falco-tetragon-and-cloud-signals.md)

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index-1/implementing-devsecops-with-docker-and-kubernetes-modernization-map.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.