Skip to main content
skill CX Codex

container-audit — Claude Code Docker & Kubernetes security skill

Skill for auditing Docker images, Dockerfiles, and Kubernetes manifests. Finds misconfigurations, excessive privileges, exposed secrets, and runtime risks.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add briiirussell/cybersecurity-skills --skill container-audit -a claude-code
Open on GitHub

What container-audit does

container-audit walks through Dockerfiles, Helm charts, Kustomize overlays, and Kubernetes manifests looking for weak base images, excess privileges, secrets baked into layers, and gaps in network isolation. It sits between cloud-audit (cloud IAM and managed services) and dependency-audit (package CVEs) as the container/orchestration layer.

The skill runs on checklists. For Dockerfiles it checks digest pinning over tags, multi-stage builds, absence of USER root and SUID binaries. For Kubernetes it checks runAsNonRoot, allowPrivilegeEscalation, NetworkPolicy, etcd encryption at rest, and RBAC roles without * on *. For runtime it checks CI image scanning via trivy image or grype, Falco/Tetragon anomaly detection, and kube-apiserver audit logs.

It starts by inventorying the surface: Dockerfiles, registries, Helm charts, CI pipelines. Then identifies the runtime — vanilla K8s, EKS, GKE, AKS, OpenShift, or ECS Fargate — and the secret model: built-in K8s Secrets, External Secrets Operator, or Vault. The catch is that K8s Secrets are just base64 by default, not encrypted, so the skill pushes for etcd encryption at rest and projected volumes instead of env vars.

What it helps with

  • Find USER root and missing non-root users in Dockerfiles
  • Detect secrets passed via --build-arg that end up in image layers
  • Verify every app namespace has a default-deny NetworkPolicy
  • Spot ClusterRoles with verbs: ["*"] on resources: ["*"]
  • Check that images are pinned by digest, not by :latest tags

Example prompts for the agent

  • Audit the Dockerfiles and Kubernetes manifests in this repository
  • Check pod security and RBAC in the project's Helm charts
  • Find secrets in images and manifests, review the secret model

How to install container-audit

1Skills CLI (Vercel)

npx skills add briiirussell/cybersecurity-skills --skill container-audit -a claude-code

2Manually: put the files in place

~/.claude/skills/container-audit/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/container-audit/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about container-audit

How do I install container-audit in Claude Code?

Run npx skills add briiirussell/cybersecurity-skills --skill container-audit -a claude-code. The skill file lands at ~/.claude/skills/container-audit/SKILL.md.

What does container-audit do?

It audits Dockerfiles, Helm charts, Kustomize overlays, and Kubernetes manifests for misconfigurations, excessive privileges, exposed secrets, and runtime security gaps. Checklists cover Dockerfile, Kubernetes, and runtime.

How is container-audit different from cloud-audit?

cloud-audit checks cloud provider IAM and managed services, dependency-audit checks CVEs in application packages. container-audit handles the container and orchestration layer between them: Docker, Kubernetes, Helm, Kustomize.

Source text

SKILL.md · MIT
---
name: container-audit
description: "Audit container images, Dockerfiles, and Kubernetes manifests for misconfigurations, excessive privileges, exposed secrets, and runtime risks. Use when the user mentions 'container security,' 'Docker security,' 'Dockerfile audit,' 'Kubernetes security,' 'K8s security,' 'pod security,' 'container hardening,' 'kubectl audit,' 'image scanning,' 'distroless,' 'rootless containers,' 'pod security policy,' 'pod security standards,' 'PSS,' 'network policy,' 'OPA Gatekeeper,' 'Kyverno,' 'runtime security,' or needs to review container or orchestration security."
allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch
---

# Container Audit — Docker & Kubernetes Security Review

Audit container images, Dockerfiles, Helm charts, Kustomize overlays, and Kubernetes manifests for misconfiguration, excessive privilege, exposed secrets, and runtime security gaps. Distinct from `cloud-audit` (cloud-provider IAM and managed services) and `dependency-audit` (package CVEs in the application). This skill is the container/orchestration layer between them.

## Scope the Audit

1. Inventory the surface — Dockerfiles, base images, registries, Helm charts, K8s manifests, Kustomize overlays, CI build pipelines that produce images
2. Identify the runtime — vanilla K8s, EKS, GKE, AKS, OpenShift, ECS Fargate, Cloud Run, Fly.io
3. Identify the network model — service mesh, ingress controller, default-deny vs default-allow
4. Identify the secret model — K8s Secrets (base64-only), External Secrets Operator, sealed-secrets, Vault, Doppler

## Audit Checklist — Dockerfile

### Base image & supply chain

- Pinned by digest, not tag — `FROM node:20@sha256:abc...` not `FROM node:20` (which can move)
- Distroless / minimal where possible — `gcr.io/distroless/nodejs20`, `alpine` (be aware of musl quirks), `chainguard/*`
- Not using `:latest` — non-reproducible builds
- Multi-stage builds discard build-time tooling — `FROM build AS builder` → `FROM runtime` final stage
- Grep for: `FROM .*:latest`, `FROM .*:[0-9]+$` (tag without digest)

### Build-time exposure

- Secrets passed via `--build-arg` end up in image layers visible to anyone who pulls the image — use BuildKit secrets (`--mount=type=secret`) or runtime env vars instead
- `COPY . .` ships everything in the build context — `.dockerignore` should exclude `.git`, `.env`, `node_modules`, `*.pem`, `.aws/`, `.ssh/`
- `ADD <url>` follows redirects and disables checksum verification — prefer `RUN curl ... && sha256sum -c`
- Grep for: `ARG .*KEY`, `ARG .*TOKEN`, `ARG .*SECRET`, `ENV .*=.*[A-Za-z0-9]{32,}`, `ADD http`

### Runtime posture

- Non-root user — `USER 1001` (or any non-zero UID) before `CMD`
- No `chmod 4755` SUID binaries in the final image
- No unnecessary shells / package managers in the final stage — distroless / FROM scratch is the strong default
- `HEALTHCHECK` defined so orchestrator can detect unhealthy containers
- Read-only root filesystem at runtime (set via K8s; verify nothing in the image writes outside `/tmp` or a declared volume)
- Grep for: `USER root` (or absence of any `USER` directive), `chmod 4755`, `apt-get install.*sudo`

## Audit Checklist — Kubernetes manifests

### Pod security

- `securityContext.runAsNonRoot: true` and `runAsUser` set to a non-zero UID
- `securityContext.allowPrivilegeEscalation: false`
- `securityContext.readOnlyRootFilesystem: true` with explicit `emptyDir` mounts where the app needs to write
- `securityContext.capabilities.drop: ["ALL"]` then add only what's needed
- `securityContext.privileged` is never `true` in app workloads (Falco, kube-proxy, some CSI drivers are the rare legit exceptions)
- `hostNetwork`, `hostPID`, `hostIPC` all `false` — yes on these is "container can see / talk to the node"
- `hostPath` volumes — every one is a node-escape risk; review case by case
- Grep for: `privileged: true`, `runAsUser: 0`, `hostNetwork: true`, `hostPath:`

### Pod Security Standards (PSS) / admission

- Cluster enforces `restricted` profile via PSS admission, or equivalent via OPA Gatekeeper / Kyverno
- Pod Security Policies (deprecated since 1.21, removed in 1.25) are NOT what's enforcing this — confirm a current admission controller
- No workloads in the `kube-system` namespace running app code

### Network

- `NetworkPolicy` exists for every namespace running app workloads — default-deny ingress AND egress, then allow specific pods
- Missing NetworkPolicy = every pod can talk to every other pod on every port, including kube-apiserver and metadata service
- Service mesh (Istio, Linkerd) mTLS in STRICT mode for sensitive namespaces, not PERMISSIVE
- Ingress controllers terminate TLS properly; backend `tls.crt` / `tls.key` in K8s Secrets rotate

### Secrets

- K8s Secrets are base64-encoded, NOT encrypted — by default they're plain bytes in etcd
- etcd encryption at rest enabled — `--encryption-provider-config` on kube-apiserver
- Workloads consume secrets via projected volumes, not environment variables (env vars leak via `/proc/<pid>/environ`, error reports, crash dumps)
- External Secrets Operator / Vault / sealed-secrets bridge so the Git repo never contains plaintext
- Grep for: `kind: Secret` in Git with `data:` fields (base64-encoded values committed)

### RBAC

- No `ClusterRole` with `*` verbs on `*` resources except `cluster-admin` (audit who's bound to it)
- `ServiceAccount` per workload, not shared "default" SA
- `automountServiceAccountToken: false` on workloads that don't need API access
- Bindings of `system:authenticated` group are visible to every legitimate workload — almost always wrong
- Grep for: `verbs: ["*"]`, `resources: ["*"]`, `apiGroups: ["*"]`, `system:authenticated`

### Resource limits

- Every container has `resources.requests` and `resources.limits` set — missing limits = noisy neighbor + DoS surface (one pod can starve the node)
- `LimitRange` per namespace as a backstop
- `ResourceQuota` per namespace prevents tenant-vs-tenant resource exhaustion

### Image policy

- `imagePullPolicy: Always` for `:latest` (you shouldn't use :latest, but if you do) — otherwise the node caches stale images
- Cluster-level policy that all images come from approved registries (your own + a small allow-list); enforced via Gatekeeper / Kyverno / image-policy-webhook
- Image signature verification — cosign + sigstore policy controller, or Notary v2

## Audit Checklist — runtime

- Image scanning in CI — `trivy image`, `grype`, `docker scout cves`. Must run on every build; advisories should not block but should surface
- Runtime detection — Falco / Tracee / Tetragon catches "shell spawned in a pod that has never opened a shell" patterns
- Audit logs enabled — kube-apiserver audit log captures `exec`, `attach`, `port-forward` events for incident response
- `kubectl exec` access tracked — not free for any cluster-admin to silently shell into prod

## Useful one-liners

```bash
# All Dockerfiles in the repo + their first FROM line
git ls-files | grep -E '(^|/)Dockerfile(\.|$)' | xargs -I{} sh -c 'echo "==> {}"; grep ^FROM "{}"'

# Manifests missing securityContext
grep -rL "securityContext" --include="*.yaml" --include="*.yml" .

# Manifests with privileged containers
grep -rln "privileged: *true" --include="*.yaml" --include="*.yml" .

# Manifests with hostPath volumes
grep -rln "hostPath:" --include="*.yaml" --include="*.yml" .

# Secrets in Git (base64-encoded but readable)
grep -rln "kind: *Secret" --include="*.yaml" --include="*.yml" . | xargs grep -l "^data:"

# Image scan (Trivy)
trivy image --severity HIGH,CRITICAL --exit-code 0 <image>

# Manifest scan (Trivy)
trivy config --severity HIGH,CRITICAL .

# Cluster posture (kube-bench, run inside the cluster)
kube-bench run --targets master,node,policies
```

## Verify Fixes at Runtime

- `runAsNonRoot: true` — verify the pod restarts cleanly and stays Running; if the image's `ENTRYPOINT` calls `chown` it'll crashloop
- NetworkPolicy default-deny — verify legitimate traffic still works (run an in-cluster `kubectl run -it --rm debug ... curl`); silent partial outages are common after default-deny rollout
- `readOnlyRootFilesystem: true` — verify the app doesn't write outside declared `emptyDir` mounts; log writes, PID files, and tmp files are common breakers
- Image-policy enforcement — try to deploy an unsigned / off-list image; verify admission rejects it

## Report Format

```markdown
# Container Security Audit
## Target: [cluster name / image registry / repo path]
## Date: [date]

### Summary
- Dockerfiles audited: N
- Manifests audited: N
- Cluster posture checks: pass / fail counts

### Findings
| ID | Severity | Category | Location | Issue |
|----|----------|----------|----------|-------|

### Per-finding detail
#### [SEVERITY] [Title]
**File:** `path/to/manifest.yaml:42`
**Category:** Dockerfile | Pod security | RBAC | NetworkPolicy | Secrets | Resource limits | Image policy | Runtime

**Description:** [what the issue is]

**Vulnerable config:**
```yaml
[snippet]
```

**Remediation:**
```yaml
[fixed snippet]
```

**Verification:** [observed behavior proving the fix holds]
```

Disposition rule (Fixed / Deferred / Accepted Risk) matches `owasp-audit`.

## Boundaries

- Only audit clusters and registries the user provides or has authorization for
- Never `kubectl delete` or modify cluster state during an audit — read-only operations only (`get`, `describe`, `auth can-i`)
- For runtime evidence, prefer non-disruptive checks (a `kubectl run -it --rm` ephemeral debug pod) over modifying running workloads
- Refuse cluster-takeover scenarios — escalating from a found weakness to a full pivot is exploitation, not audit
- Flag low-confidence findings as "Potential" rather than confirmed

## References

- CIS Docker Benchmark
- CIS Kubernetes Benchmark
- NSA/CISA Kubernetes Hardening Guide
- Pod Security Standards (PSS) — restricted, baseline, privileged
- OWASP Docker Security Cheat Sheet
- OWASP Kubernetes Security Cheat Sheet
- MITRE ATT&CK for Containers

© briiirussell · MIT · briiirussell/cybersecurity-skills

Similar skills

All skills for Security →

From the same set25

privacy-engineering A skill that helps your AI agent implement and audit privacy controls in code and infrastructure: GDPR, CCPA/CPRA, LGPD, PIPEDA. CX Codex +1 352installs crypto-audit Reviews how cryptography is implemented in your code: cipher modes, KDF parameters, IV and nonce handling, signature checks. Useful when the code looks right but still leaks. CX Codex +1 353installs iam-audit Audits cloud and IdP access policies, designs greenfield RBAC models, and plans identity migrations. Useful when untangling privilege creep or moving to SSO. CX Codex +1 351installs cloud-audit This skill checks AWS, GCP and Azure configurations for misconfigurations, excessive permissions and public exposure. Useful before a release or after an incident. CX Codex +1 352installs red-team-engagement Plans and coordinates authorized adversary emulation engagements to test detection and response. Fits assumed-breach exercises, Rules of Engagement drafting, and blue-team deconfliction. CX Codex +1 336installs threat-hunting Proactively hunts for adversaries in SIEM, EDR, and logs before alerts fire. Guides hypothesis-driven investigations using the PEAK framework and MITRE ATT&CK. CX Codex +1 333installs siem-detection Engineers and audits SIEM detection rules across Sigma, KQL, SPL, and Elastic, mapping coverage against MITRE ATT&CK. CX Codex +1 330installs security-comms Translates technical security findings and incident write-ups into tailored updates for executives, engineers, legal, and customers. CX Codex +1 328installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor