container-audit
Skill0 starsChanged 2 months agoMITView on GitHub
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.
- Reads credentials
- Installs packages
3 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- briiirussell/cybersecurity-skillsedited, first seen Nov 1, 2026
- greglas75/zuvotheir own version, first seen Oct 16, 2026
- gricha/dangerous-skillstheir own version, first seen Mar 23, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- briiirussell/cybersecurity-skills★ 48944% same
Wrote their own version · 2
- gricha/dangerous-skills★ 38same name
- greglas75/zuvo★ 7same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- cybersecurity-skillsSkill
- ai-risk-managementSkill
- api-auditSkill
- breach-patternsSkill
- cloud-auditSkill
- crypto-auditSkill
- csf-mappingSkill
- dependency-auditSkill
- disk-forensicsSkill
- finding-triageSkill
- hipaa-auditSkill
- iam-auditSkill
- incident-triageSkill
- mobile-auditSkill
- osint-reconSkill
- owasp-auditSkill
- pci-auditSkill
- privacy-engineeringSkill
- prompt-injectionSkill
- reconSkill
- red-team-engagementSkill
- secrets-auditSkill
- security-commsSkill
- siem-detectionSkill
- soc-operationsSkill
- threat-huntingSkill
- threat-modelingSkill
- vuln-researchSkill
- web-pentestSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 2 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
Not using :latest — non-reproducible builds
- Distinctive: line 39
No unnecessary shells / package managers in the final stage — distroless / FROM scratch is the strong default
- Very specific: line 41
Read-only root filesystem at runtime (set via K8s.
- Very specific: line 61
No workloads in the kube-system namespace running app code
- Very specific: line 88
Every container has resources.requests and resources.limits set — missing limits = noisy neighbor + DoS surface (one pod can starve the …
- Distinctive: line 180
Only audit clusters and registries the user provides or has authorization for
- Very specific: line 181
Never kubectl delete or modify cluster state during an audit — read-only operations only (get, describe, auth can-i)
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
- Inventory the surface — Dockerfiles, base images, registries, Helm charts, K8s manifests, Kustomize overlays, CI build pipelines that produce images
- Identify the runtime — vanilla K8s, EKS, GKE, AKS, OpenShift, ECS Fargate, Cloud Run, Fly.io
- Identify the network model — service mesh, ingress controller, default-deny vs default-allow
- 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...notFROM 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 runtimefinal stage - Grep for:
FROM .*:latest,FROM .*:[0-9]+$(tag without digest)
Build-time exposure
- Secrets passed via
--build-argend 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 —.dockerignoreshould exclude.git,.env,node_modules,*.pem,.aws/,.ssh/ADD <url>follows redirects and disables checksum verification — preferRUN 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) beforeCMD - No
chmod 4755SUID binaries in the final image - No unnecessary shells / package managers in the final stage — distroless / FROM scratch is the strong default
HEALTHCHECKdefined so orchestrator can detect unhealthy containers- Read-only root filesystem at runtime (set via K8s; verify nothing in the image writes outside
/tmpor a declared volume) - Grep for:
USER root(or absence of anyUSERdirective),chmod 4755,apt-get install.*sudo
Audit Checklist — Kubernetes manifests
Pod security
securityContext.runAsNonRoot: trueandrunAsUserset to a non-zero UIDsecurityContext.allowPrivilegeEscalation: falsesecurityContext.readOnlyRootFilesystem: truewith explicitemptyDirmounts where the app needs to writesecurityContext.capabilities.drop: ["ALL"]then add only what's neededsecurityContext.privilegedis nevertruein app workloads (Falco, kube-proxy, some CSI drivers are the rare legit exceptions)hostNetwork,hostPID,hostIPCallfalse— yes on these is "container can see / talk to the node"hostPathvolumes — 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
restrictedprofile 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-systemnamespace running app code
Network
NetworkPolicyexists 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.keyin 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-configon 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: Secretin Git withdata:fields (base64-encoded values committed)
RBAC
- No
ClusterRolewith*verbs on*resources exceptcluster-admin(audit who's bound to it) ServiceAccountper workload, not shared "default" SAautomountServiceAccountToken: falseon workloads that don't need API access- Bindings of
system:authenticatedgroup are visible to every legitimate workload — almost always wrong - Grep for:
verbs: ["*"],resources: ["*"],apiGroups: ["*"],system:authenticated
Resource limits
- Every container has
resources.requestsandresources.limitsset — missing limits = noisy neighbor + DoS surface (one pod can starve the node) LimitRangeper namespace as a backstopResourceQuotaper namespace prevents tenant-vs-tenant resource exhaustion
Image policy
imagePullPolicy: Alwaysfor: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-forwardevents for incident response kubectl execaccess tracked — not free for any cluster-admin to silently shell into prod
Useful one-liners
# 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,policiesVerify Fixes at Runtime
runAsNonRoot: true— verify the pod restarts cleanly and stays Running; if the image'sENTRYPOINTcallschownit'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 declaredemptyDirmounts; 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
# 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:
[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 ContainersDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

