Docker & Kubernetes Security Posture Kit

Nobody had to be clever. They just had to look. In 2018 a car maker's Kubernetes dashboard was found exposed to the public internet with no authentication at all, and an attacker deployed pods inside the cluster to mine cryptocurrency on the victim's own cloud bill. No zero-day. One missing control. It is still the textbook example in 2026 hardening guides because the pattern has not gone away: automated scanners continuously probe the API server on 6443, the kubelet on 10250 and etcd on 2379 across the whole public internet.

Docker and Kubernetes in one kit, on purpose. A container-escape finding and a cluster-RBAC finding are two ends of the same attack chain, not two assessments. A container-level misconfiguration — privileged mode, a mounted Docker socket, no seccomp profile — is frequently step one, and a cluster-level one — the default service account auto-mounted, a wildcard binding, an exposed API server — is what turns step one into full cluster or cloud-account compromise. The kit follows that chain in a single pass.

The connective finding is the pivot to the cloud. A compromised pod's auto-mounted service-account token enumerates RBAC, escalates, and reaches the cloud account's IAM and metadata service. That is the pattern the 2026 incident research keeps returning to, and it is why the container layer belongs in this kit: it is where the chain starts. Two facts the kit weights highest because they are easy to miss and catastrophic if missed: system:authenticated includes every service-account token the API server issues, so a binding to it is a binding to every pod; and base64 is not encryption — a direct etcd connection bypasses Kubernetes RBAC entirely, so etcd gets its own weighted-high rows.

Both CIS benchmarks are real, and file 04 cites them. The CIS Docker Benchmark and the CIS Kubernetes Benchmark — the latter alone runs to over a hundred checks — are condensed to the highest-impact controls with section references per row. No substitution, no invented framework.

The detection finding is a wiring gap. Kubernetes audit logging is not on by default. And catching the cloud pivot specifically requires correlating cluster audit logs with the cloud provider's control-plane logs, which almost nobody has wired together. File 06 makes that row the headline.

What you get

01 Assessment Methodology (DOCX) — why both layers together, the pivot as the central attack chain, the five modules, run order, cross-links and assumptions.

02 Identity & Access Review Workbook (XLSX) — RBAC Structure (least-privilege roles, cluster-admin count, no bindings to system:authenticated or system:unauthenticated, review cadence), Service Account Hygiene (auto-mount off by default, one account per workload, time-bound tokens), Cluster Access Control (kubeconfig distribution, cloud-IAM federation for managed clusters, break-glass) and Docker Daemon & Registry Access, rolling into one identity posture score.

03 Blast Radius Scoring Tool (XLSX) — the flagship module. Record the Deployment Model first — self-managed or EKS/AKS/GKE, runtime, public endpoint and its allowlist, registry, secrets manager — pull current ClusterRoleBindings, then answer the control questions across exposed control plane, RBAC & service accounts, workload isolation, and secrets & etcd. One score, a band on the same bands as the sibling kits, and a closure list ranked by risk-weighted points.

04 CIS-Aligned Hardening Checklist (XLSX) — Docker Host & Runtime (minimal base images, no privileged containers, non-root by default), Kubernetes Control Plane (anonymous auth off, API server behind an allowlist, etcd client-certificate auth, kubelet webhook authorisation), Kubernetes RBAC (CIS 5.1) and Workload & Audit Hardening (Pod Security Standards, default-deny network policies, seccomp, audit logging), scored gap-to-target.

05 Data Governance Review (DOCX) — the supply chain feeding the cluster: image provenance and SBOM coverage, digest pinning over mutable tags, pre-deploy scanning, the secrets-management approach, and registry access control.

06 Detection Readiness Matrix (XLSX) — Kubernetes audit log, runtime detection, Docker daemon logs, cloud control-plane logs and registry logs, each row stating whether it is on by default and whether it reaches the cloud-IAM pivot.

07 Executive Summary Template (DOCX) — one page with a plain-language section and a technical-detail section for the platform team, because this kit's reader is as likely to be a platform lead as a board.

ctr01.json — scoring bands, surfaces, deployment-model components, the two CIS benchmarks and the module map.

A worked example throughout. Ferroglass Systems, a fictional fintech and logistics platform running Docker for local development and CI and a managed cluster in production, with the public API endpoint restricted to office and VPN ranges and everything else still to prove.

Where it sits. If the cluster is deployed via GitOps or CI/CD, the GitHub / GitLab Security Posture Kit covers the pipeline — run both blast-radius modules for the full chain. The Vibe-Coded App Security Posture Kit covers an AI-built application tier above the cluster. Pillar 02 — the DevSecOps Risk Register and Bug-Hunter Automation are the build layer. The IR Runbook Library is the response layer — runbook 07 is a supply-chain compromise. Run it against a vendor's cluster with the TPRM Program Kit; hand file 07 to the Director's Cyber Oversight Kit. Managed Kubernetes inherits the cloud account's IAM risk; the AWS, Azure and Google Cloud posture kits assess that account on the same bands.

Written against Kubernetes, Docker, EKS/AKS/GKE defaults and the CIS Docker and Kubernetes Benchmarks as of Q3 2026, marked verify. Benchmark references are section mappings to a condensed control set, not full-benchmark coverage. Not a penetration test. Scores are a prioritisation aid, not a certification, an audit opinion or an insurance-underwriting determination. Not legal advice.