docs(skills): rewrite container-security descriptions to a uniform standard

All 33 container-security skills now carry what it does, an explicit
"Use when" trigger, keywords, and a negative trigger naming the nearest
neighbour. Six collision clusters resolved by differentiating scope
rather than merging, so no skill is removed:

- kube-bench: running the tool vs interpreting findings into an audit
- Calico: portable upstream NetworkPolicy vs Calico-as-CNI vs Calico-only
  CRDs (GlobalNetworkPolicy, HostEndpoint, DNS egress)
- Falco: deploying and operating it vs authoring escape rules
- container escape: tool-agnostic runtime signals vs Falco rule syntax vs
  static posture audit vs offensive breakout
- Trivy: all-target platform and operator vs single-image scan
- Docker: images and Dockerfiles vs daemon.json vs the CIS audit script

Also replaces the templated "When to Use" boilerplate in these files,
including bullets that only restated the skill's own name.

Worst pair (Pod Security Standards vs Pod Security Admission) drops from
0.77 cosine to below the 0.45 threshold. Repo-wide: colliding pairs
60 -> 56, skills involved 105 -> 94.
This commit is contained in:
Mahipal
2026-08-23 17:15:30 +02:00
parent a81b233649
commit 6972fe933e
33 changed files with 300 additions and 149 deletions
@@ -1,9 +1,13 @@
--- ---
name: analyzing-kubernetes-audit-logs name: analyzing-kubernetes-audit-logs
description: 'Parses Kubernetes API server audit logs (JSON lines) to detect exec-into-pod, description: >-
secret access, RBAC modifications, privileged pod creation, and anonymous API access. Parses Kubernetes API server audit logs (JSON lines) to detect exec-into-pod, secret access,
Builds threat detection rules from audit event patterns. Use when investigating RBAC modifications, privileged pod creation, and anonymous API access, and builds SIEM
Kubernetes cluster compromise or building k8s-specific SIEM detection rules. detection rules from the event patterns. Use when investigating a suspected cluster
compromise, reconstructing what an attacker did through the API server, or writing
Kubernetes-specific detection content. Keywords: audit policy, audit log, kube-apiserver,
exec into pod, RBAC change, anonymous access, detection rules. Do not use for syscall-level
detection inside a running container - use detecting-container-runtime-threats-with-falco.
' '
domain: cybersecurity domain: cybersecurity
@@ -1,6 +1,13 @@
--- ---
name: auditing-kubernetes-rbac-privilege-escalation name: auditing-kubernetes-rbac-privilege-escalation
description: Find over-permissive RBAC roles and service-account token abuse paths in Kubernetes using kubectl auth can-i, rbac-police, kubectl-who-can, and rakkess during authorized cluster security reviews. description: >-
Finds over-permissive RBAC roles and service-account token abuse paths in a Kubernetes
cluster using kubectl auth can-i, rbac-police, kubectl-who-can, and rakkess, tracing which
subjects can escalate toward cluster-admin. Use when reviewing who can escalate privileges
in a cluster, hunting exploitable RoleBindings during an authorized review, or validating
least privilege after an RBAC change. Keywords: RBAC, ClusterRoleBinding, service account
token, auth can-i, rbac-police, escalate, bind, impersonate. Do not use for designing and
applying hardened RBAC - use implementing-rbac-hardening-for-kubernetes.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,6 +1,14 @@
--- ---
name: benchmarking-kubernetes-with-kube-bench name: benchmarking-kubernetes-with-kube-bench
description: Run kube-bench (Aqua Security) against a Kubernetes cluster's control-plane, kubelet, and node configuration to check compliance with the CIS Kubernetes Benchmark and remediate PASS/FAIL/WARN findings. Use when establishing a security baseline for a new cluster, performing periodic hardening audits, validating remediation after configuration changes, or gathering compliance evidence for SOC 2/PCI DSS. description: >-
Installs and runs the kube-bench tool against a Kubernetes cluster as a Job, DaemonSet, or
standalone binary, selecting the correct benchmark version and targets (control plane, etcd,
kubelet, worker nodes) and emitting JSON or JUnit output for pipelines. Use when setting
kube-bench up for the first time, choosing which benchmark version and node targets to run,
wiring it into CI, or troubleshooting skipped or misdetected checks. Keywords: kube-bench,
DaemonSet, --benchmark, --targets, JSON output, JUnit, CI integration. Do not use for
interpreting the findings or producing an audit report - use
performing-kubernetes-cis-benchmark-with-kube-bench.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,6 +1,14 @@
--- ---
name: detecting-container-drift-at-runtime name: detecting-container-drift-at-runtime
description: Detect unauthorized runtime drift in containers by monitoring binary execution, file system changes, and configuration deviations from the original immutable image, using tools like Falco and Microsoft Defender for Kubernetes/container workloads. Use when investigating possible container compromise, validating immutable-infrastructure controls, or hunting for unexpected package installs and file modifications inside running containers. description: >-
Detects unauthorized runtime drift in containers by monitoring binary execution, filesystem
changes, and configuration deviation from the original immutable image, using Falco and
Microsoft Defender for Containers. Use when validating immutable-infrastructure controls,
hunting for unexpected package installs or binaries written inside a running container, or
determining whether a container diverged from the image it was built from. Keywords: drift,
immutable infrastructure, new binary executed, package install, image mismatch, Falco. Do
not use for detecting breakout from the container to the host - use
detecting-container-escape-attempts.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,6 +1,15 @@
--- ---
name: detecting-container-escape-attempts name: detecting-container-escape-attempts
description: Detect container escape attempts where an adversary breaks out of container isolation to reach the host or other containers, by monitoring namespace manipulation, capability abuse, kernel exploits, sensitive mounted paths, and anomalous syscalls with tools like Falco, Sysdig, and seccomp/audit rules. Use when hunting for privilege escalation from containerized workloads or investigating suspected breakout from a Docker/Kubernetes environment. description: >-
Detects container escape at runtime across tooling - namespace manipulation, capability
abuse, kernel exploits, sensitive host mounts, and anomalous syscalls - and explains which
signals matter regardless of whether Falco, Sysdig, auditd, or an EDR is doing the
collection. Use when deciding what breakout behaviour to monitor, investigating a suspected
Docker or Kubernetes breakout, or comparing escape coverage across runtime sensors.
Keywords: container escape, breakout, namespaces, CAP_SYS_ADMIN, privileged, hostPath,
kernel exploit, syscall. Do not use for Falco rule syntax itself - use
detecting-container-escape-with-falco-rules; for a static configuration sweep use
performing-container-escape-detection.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,6 +1,14 @@
--- ---
name: detecting-container-escape-with-falco-rules name: detecting-container-escape-with-falco-rules
description: Write and tune Falco rules that monitor Linux syscalls to detect container escape techniques in real time, including host filesystem mounts, sensitive host path access, kernel module loading, and abuse of privileged container capabilities. Use when deploying or tuning Falco for a Kubernetes/container environment, or when investigating an alert tied to syscall-level escape behavior. description: >-
Writes and tunes Falco rule syntax for container escape detection - conditions, macros,
lists, priorities, and output fields - covering host filesystem mounts, sensitive host path
access, kernel module loading, and privileged capability abuse, including how to drive down
false positives. Use when authoring or tuning a specific Falco rule for breakout behaviour,
or triaging a noisy escape-related Falco alert. Keywords: Falco rule, macro, list,
condition, priority, falco_rules.local.yaml, tuning, false positive. Do not use for
deploying and operating Falco itself - use detecting-container-runtime-threats-with-falco;
for tool-agnostic escape signals use detecting-container-escape-attempts.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,6 +1,13 @@
--- ---
name: detecting-container-runtime-threats-with-falco name: detecting-container-runtime-threats-with-falco
description: Write and deploy Falco rules with the modern eBPF driver to detect container escape, namespace abuse, privileged mounts, and anomalous syscalls at runtime in Kubernetes and Docker. description: >-
Deploys and operates Falco with the modern eBPF driver in Kubernetes and Docker, covering
driver selection, Helm installation, output channels, and the built-in ruleset that detects
container escape, namespace abuse, privileged mounts, and anomalous syscalls. Use when
standing Falco up on a cluster, choosing between the eBPF and kernel-module drivers, routing
Falco alerts into a SIEM or Falcosidekick, or upgrading an existing deployment. Keywords:
Falco, modern_ebpf, kernel module, Helm, Falcosidekick, runtime security, syscall. Do not
use for authoring individual escape rules - use detecting-container-escape-with-falco-rules.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,13 @@
--- ---
name: detecting-privilege-escalation-in-kubernetes-pods name: detecting-privilege-escalation-in-kubernetes-pods
description: Detect and prevent privilege escalation in Kubernetes pods by combining description: >-
admission control (OPA policies), runtime monitoring (Falco), and audit log Detects and prevents privilege escalation inside Kubernetes pods by combining admission
analysis of security contexts, Linux capabilities, and syscall patterns. Use control (OPA policies), runtime monitoring (Falco), and audit log analysis of security
when hardening pod security policies, investigating a pod running as root or contexts, Linux capabilities, and syscall patterns. Use when investigating a pod running as
privileged, or hunting for containers escaping their intended scope. root or privileged, hardening workloads against in-pod escalation, or hunting for containers
exceeding their intended scope. Keywords: allowPrivilegeEscalation, runAsRoot, capabilities,
securityContext, OPA, Falco, audit log. Do not use for escalation through RBAC and
service-account permissions - use auditing-kubernetes-rbac-privilege-escalation.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
+8 -1
View File
@@ -1,6 +1,13 @@
--- ---
name: escaping-containers-to-host name: escaping-containers-to-host
description: Exploit privileged pods, host mounts, runC CVEs, and exposed Docker sockets to break out of a container and reach the underlying host during authorized container-security assessments. description: >-
Exploits privileged pods, host mounts, runC CVEs, and exposed Docker sockets to break out of
a container and reach the underlying host during an authorized container-security
assessment. Use when executing an approved breakout test, demonstrating the real impact of a
privileged or hostPath workload, or validating that escape mitigations actually hold.
Keywords: container breakout, privileged, hostPath, docker.sock, runC CVE-2019-5736,
CVE-2024-21626, release_agent, nsenter. Do not use for defensive detection of these
techniques - use detecting-container-escape-attempts.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,12 +1,13 @@
--- ---
name: hardening-docker-containers-for-production name: hardening-docker-containers-for-production
description: > description: >-
Harden Dockerfiles, images, and container runtime settings against the CIS Hardens Dockerfiles, images, and per-container runtime settings against the CIS Docker
Docker Benchmark v1.8.0: non-root users, dropped capabilities, read-only Benchmark v1.8.0: non-root users, dropped capabilities, read-only root filesystem, seccomp
rootfs, seccomp/AppArmor, and minimal multi-stage images, validated with and AppArmor profiles, and minimal multi-stage builds, validated with docker-bench-security,
docker-bench-security, Hadolint, and Dockle. Use when preparing a container Hadolint, and Dockle. Use when preparing a container or Dockerfile for production, or
or Dockerfile for production, or auditing images/runtime configs against auditing images and runtime flags against CIS Docker controls. Keywords: Dockerfile, USER,
CIS Docker controls. --cap-drop, read-only rootfs, seccomp, AppArmor, multi-stage, Hadolint, Dockle. Do not use
for the Docker daemon's own configuration - use hardening-docker-daemon-configuration.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,6 +1,13 @@
--- ---
name: hardening-docker-daemon-configuration name: hardening-docker-daemon-configuration
description: Harden the Docker daemon (dockerd) by configuring /etc/docker/daemon.json with user namespace remapping, TLS client authentication, seccomp profiles, and CIS Docker Benchmark controls such as icc, no-new-privileges, and live-restore. Use when securing a Docker host's daemon configuration to prevent privilege escalation, container breakout, or lateral movement, or when auditing daemon settings against CIS benchmark requirements. description: >-
Hardens the Docker daemon (dockerd) through /etc/docker/daemon.json with user namespace
remapping, TLS client authentication, seccomp profiles, and CIS Docker Benchmark controls
such as icc, no-new-privileges, and live-restore. Use when securing a Docker host's daemon
to prevent privilege escalation, breakout, or lateral movement, or when auditing daemon
settings against CIS requirements. Keywords: dockerd, daemon.json, userns-remap,
no-new-privileges, icc, live-restore, TLS socket. Do not use for hardening images and
per-container runtime flags - use hardening-docker-containers-for-production.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,11 +1,13 @@
--- ---
name: implementing-container-image-minimal-base-with-distroless name: implementing-container-image-minimal-base-with-distroless
description: Reduces container attack surface by building application images on Google description: >-
distroless base images that contain only the app runtime with no shell, package Reduces container attack surface by building application images on Google distroless base
manager, or OS utilities, using multi-stage Docker build patterns and debug/scanning images that ship only the application runtime - no shell, package manager, or OS utilities -
techniques for distroless containers. Use when hardening container images, cutting using multi-stage build patterns plus debugging and scanning techniques adapted to
attack surface in a container security architecture, or responding to a security distroless. Use when hardening container images, cutting attack surface in a container
assessment that flags bloated base images. architecture, or answering an assessment finding about bloated base images. Keywords:
distroless, multi-stage build, no shell, nonroot tag, debug image, scratch, attack surface.
Do not use for scanning an image for known CVEs - use scanning-docker-images-with-trivy.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,14 @@
--- ---
name: implementing-container-network-policies-with-calico name: implementing-container-network-policies-with-calico
description: Enforces Kubernetes network segmentation by creating and auditing Calico description: >-
NetworkPolicy and GlobalNetworkPolicy resources via calicoctl and the Kubernetes Uses Calico's own policy CRDs beyond the upstream Kubernetes API - GlobalNetworkPolicy,
API, controlling pod-to-pod traffic, namespace isolation, egress restrictions, and HostEndpoint, NetworkSet, policy tiers, and DNS-based egress rules - applied and audited
DNS-based rules. Use when implementing zero-trust microsegmentation in a Calico-CNI with calicoctl. Use when a policy must span namespaces or protect the host itself, when
cluster or hardening pod-to-pod and egress traffic controls. egress has to be expressed by domain name, or when ordering policies into tiers. Keywords:
calicoctl, GlobalNetworkPolicy, HostEndpoint, NetworkSet, tier, DNS egress, order. Do not
use for portable upstream NetworkPolicy - use implementing-network-policies-for-kubernetes;
for installing Calico and writing standard policy with it use
implementing-kubernetes-network-policy-with-calico.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,11 +1,13 @@
--- ---
name: implementing-image-provenance-verification-with-cosign name: implementing-image-provenance-verification-with-cosign
description: Signs and verifies container image provenance using Sigstore Cosign, description: >-
covering key-based and keyless OIDC-based signing (Fulcio, Rekor transparency log), Signs and verifies container image provenance with Sigstore Cosign, covering key-based and
SLSA attestations, and enforcing signature verification via Kubernetes admission keyless OIDC signing (Fulcio, Rekor transparency log), SLSA attestations, and enforcing
control. Use when signing container images for supply chain security, setting signature verification through Kubernetes admission control. Use when signing images for
up keyless OIDC signing, attaching attestations, or enforcing verified-image-only supply chain security, setting up keyless OIDC signing, attaching attestations, or enforcing
policies at admission in a Kubernetes cluster. a verified-images-only policy at admission. Keywords: Cosign, Sigstore, Fulcio, Rekor,
keyless, attestation, cosign verify, admission policy. Do not use for in-toto layout-based
pipeline attestation - use implementing-supply-chain-security-with-in-toto.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,12 +1,15 @@
--- ---
name: implementing-kubernetes-network-policy-with-calico name: implementing-kubernetes-network-policy-with-calico
description: >- description: >-
Implements Kubernetes network segmentation using Calico's Kubernetes Installs Calico as the cluster CNI and writes standard Kubernetes NetworkPolicy under it,
NetworkPolicy and GlobalNetworkPolicy resources, including default-deny rules, covering default-deny baselines, policy ordering and precedence, service-account-based
policy ordering, and service-account-based selectors for zero-trust selectors, and verifying that policy is genuinely being enforced. Use when adopting Calico
pod-to-pod communication. Use when installing Calico CNI and writing or as the enforcement CNI, establishing a default-deny baseline, or debugging why a
auditing network policies to restrict east-west traffic within a Kubernetes NetworkPolicy is not taking effect under Calico. Keywords: Calico CNI, NetworkPolicy,
cluster. default deny, policy order, Felix, service account selector. Do not use for Calico-only CRDs
such as GlobalNetworkPolicy or DNS egress - use
implementing-container-network-policies-with-calico; for CNI-agnostic policy use
implementing-network-policies-for-kubernetes.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,12 +1,17 @@
--- ---
name: implementing-kubernetes-pod-security-standards name: implementing-kubernetes-pod-security-standards
description: >- description: >-
Configures Kubernetes Pod Security Standards (Privileged, Baseline, Restricted) Chooses and applies the correct Kubernetes Pod Security Standard (Privileged,
enforced via the built-in Pod Security Admission (PSA) controller (Kubernetes Baseline, Restricted) for a workload: what each profile forbids, how to map
1.25+), including namespace labeling and enforce/audit/warn modes. Use when existing workloads to a profile, which securityContext fields must change, and
hardening pod configurations against privilege escalation, migrating off how to plan a PodSecurityPolicy-to-PSS migration without breaking running pods.
deprecated PodSecurityPolicy, or setting namespace-level pod security Use when deciding which pod security profile a namespace or workload should run
enforcement. under, auditing which workloads would fail Restricted, planning a PSP migration,
or mapping pod security posture to a compliance control. Keywords: Pod Security
Standards, PSS, Privileged, Baseline, Restricted, securityContext, runAsNonRoot,
drop ALL capabilities, seccomp RuntimeDefault, PSP migration. Do not use for
configuring the admission controller that enforces these profiles - use
implementing-pod-security-admission-controller.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -38,10 +43,15 @@ Pod Security Standards (PSS) define three levels of security policies -- Privile
## When to Use ## When to Use
- When deploying or configuring implementing kubernetes pod security standards capabilities in your environment - Deciding whether a namespace or workload belongs at Privileged, Baseline, or Restricted
- When establishing security controls aligned to compliance requirements - Auditing which existing workloads would be rejected if Restricted were enforced today
- When building or improving security architecture for this domain - Translating a "must meet Restricted" requirement into concrete `securityContext` changes
- When conducting security assessments that require this implementation - Planning a PodSecurityPolicy migration and predicting what will break before it does
- Mapping pod security posture to a compliance control (NIST PR.PS-01, CIS Kubernetes)
**Not this skill:** configuring the controller that enforces these profiles — namespace
labels, `AdmissionConfiguration`, exemptions, or debugging a pod PSA rejected. Use
`implementing-pod-security-admission-controller`.
## Prerequisites ## Prerequisites
@@ -1,10 +1,13 @@
--- ---
name: implementing-network-policies-for-kubernetes name: implementing-network-policies-for-kubernetes
description: Writes Kubernetes NetworkPolicy YAML (default-deny-all, DNS egress, namespace/pod description: >-
selector rules) enforced via CNI plugins like Calico or Cilium to control ingress Writes portable upstream Kubernetes NetworkPolicy YAML - default-deny-all, DNS egress,
and egress traffic between pods, namespaces, and external endpoints. Use when namespace and pod selector rules - that works on any conformant CNI such as Calico or
implementing zero-trust microsegmentation inside a Kubernetes cluster to prevent Cilium. Use when segmentation must stay CNI-portable, introducing a default-deny posture, or
lateral movement between workloads or namespaces. restricting east-west traffic between pods and namespaces without depending on a vendor CRD.
Keywords: NetworkPolicy, default deny, podSelector, namespaceSelector, ingress, egress, CNI
portable. Do not use for Calico-specific resources - use
implementing-kubernetes-network-policy-with-calico.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,14 @@
--- ---
name: implementing-opa-gatekeeper-for-policy-enforcement name: implementing-opa-gatekeeper-for-policy-enforcement
description: Deploys OPA Gatekeeper via Helm as a Kubernetes admission controller and writes description: >-
ConstraintTemplates with Rego rules plus instantiated Constraints to validate, Deploys OPA Gatekeeper via Helm as a Kubernetes admission controller and writes
mutate, or deny resource requests at admission time. Use when enforcing policy-as-code ConstraintTemplates with Rego plus instantiated Constraints to validate, mutate, or deny
admission control in a Kubernetes cluster (v1.24+), such as blocking non-compliant resource requests at admission time. Use when enforcing custom policy-as-code at admission
workloads before they are scheduled. on Kubernetes v1.24+, blocking non-compliant workloads before scheduling, or expressing a
rule that built-in controls cannot. Keywords: Gatekeeper, ConstraintTemplate, Constraint,
Rego, admission webhook, audit, mutation. Do not use for the standard pod security profiles
that Pod Security Admission already covers - use
implementing-pod-security-admission-controller.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,17 @@
--- ---
name: implementing-pod-security-admission-controller name: implementing-pod-security-admission-controller
description: Implement Kubernetes Pod Security Admission (PSA), the built-in admission description: >-
controller stable since v1.25, to enforce Privileged, Baseline, and Restricted Configures and operates the Kubernetes Pod Security Admission (PSA) controller
Pod Security Standards at the namespace level with enforce, audit, and warn modes, that enforces Pod Security Standards: namespace enforce/audit/warn labels,
replacing the deprecated PodSecurityPolicy. Use when hardening Kubernetes namespaces, cluster-wide defaults via AdmissionConfiguration, exemptions for usernames,
migrating off PodSecurityPolicy, or enforcing pod-level security baselines. runtime classes and namespaces, version pinning, and troubleshooting pods the
controller rejected. Use when wiring PSA up on a cluster, setting cluster-wide
default enforcement, exempting system namespaces, debugging why a pod was
rejected or why enforcement is not firing, or reading PSA audit and warning
output. Keywords: Pod Security Admission, PSA, admission controller,
AdmissionConfiguration, pod-security.kubernetes.io labels, enforce audit warn,
exemptions, kube-apiserver. Do not use for choosing which security profile a
workload needs - use implementing-kubernetes-pod-security-standards.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -37,10 +44,16 @@ Pod Security Admission (PSA) is a built-in Kubernetes admission controller (stab
## When to Use ## When to Use
- When deploying or configuring implementing pod security admission controller capabilities in your environment - Wiring PSA up on a cluster for the first time
- When establishing security controls aligned to compliance requirements - Setting cluster-wide default enforcement via `AdmissionConfiguration`
- When building or improving security architecture for this domain - Exempting system namespaces, service accounts, or runtime classes from enforcement
- When conducting security assessments that require this implementation - Debugging why a pod was rejected, or why enforcement is silently not firing
- Staging a safe rollout: `warn` and `audit` first, `enforce` once violations reach zero
- Pulling PSA violations out of the kube-apiserver audit log
**Not this skill:** deciding which profile a workload should run under, or what
`securityContext` changes Restricted demands. Use
`implementing-kubernetes-pod-security-standards`.
## Prerequisites ## Prerequisites
@@ -1,10 +1,13 @@
--- ---
name: implementing-rbac-hardening-for-kubernetes name: implementing-rbac-hardening-for-kubernetes
description: Harden Kubernetes RBAC by implementing least-privilege Roles and ClusterRoles, description: >-
auditing RoleBindings, eliminating cluster-admin sprawl, separating service accounts, Hardens Kubernetes RBAC by designing least-privilege Roles and ClusterRoles, auditing
and integrating external identity providers (OIDC). Use when reviewing or tightening RoleBindings, eliminating cluster-admin sprawl, separating service accounts, and integrating
Kubernetes access control, removing excessive ClusterRoleBindings, or hardening an external OIDC identity provider. Use when tightening cluster access control, removing
service-account permissions against privilege escalation and lateral movement. excessive ClusterRoleBindings, or hardening service-account permissions against escalation
and lateral movement. Keywords: RBAC, Role, ClusterRole, RoleBinding, least privilege,
service account, OIDC, cluster-admin. Do not use for discovering existing escalation paths -
use auditing-kubernetes-rbac-privilege-escalation.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,13 @@
--- ---
name: implementing-runtime-security-with-tetragon name: implementing-runtime-security-with-tetragon
description: Implement eBPF-based runtime security observability and enforcement in description: >-
Kubernetes clusters using Cilium Tetragon, monitoring process execution, file access, Implements eBPF-based runtime observability and in-kernel enforcement in Kubernetes with
network connections, and syscalls at the kernel level. Use when deploying Tetragon Cilium Tetragon, monitoring process execution, file access, network connections, and
to detect or block dangerous syscalls (ptrace, mount, unshare), enforce kernel-level syscalls, and blocking dangerous calls at the kernel level. Use when deploying Tetragon to
Kubernetes security policy, or add low-overhead runtime threat detection to a cluster. detect or block syscalls such as ptrace, mount, and unshare, enforcing kernel-level policy,
or adding low-overhead runtime detection to a cluster. Keywords: Tetragon, Cilium, eBPF,
TracingPolicy, kprobe, enforcement, process lineage. Do not use for Falco-based detection -
use detecting-container-runtime-threats-with-falco.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,12 +1,13 @@
--- ---
name: implementing-supply-chain-security-with-in-toto name: implementing-supply-chain-security-with-in-toto
description: Implement software supply chain integrity verification for container description: >-
builds using the in-toto framework, covering signing-key generation, defining a Implements supply chain integrity verification for container builds with the in-toto
supply chain layout, recording pipeline steps as signed link metadata, verifying framework: generating signing keys, defining a supply chain layout, recording pipeline steps
before deployment, Kubernetes admission control, and SLSA integration. Use when as signed link metadata, verifying before deployment, enforcing at Kubernetes admission, and
generating in-toto attestations for CI/CD pipeline steps, verifying that a container integrating with SLSA. Use when attesting CI/CD pipeline steps, proving an image followed
image followed an approved build process, or enforcing supply chain provenance the approved build process, or enforcing provenance at admission. Keywords: in-toto, layout,
at admission time. link metadata, step, inspection, SLSA, provenance, admission. Do not use for signing and
verifying images with Cosign - use implementing-image-provenance-verification-with-cosign.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,9 +1,13 @@
--- ---
name: performing-container-escape-detection name: performing-container-escape-detection
description: 'Detects container escape attempts by analyzing namespace configurations, description: >-
privileged container checks, dangerous capability assignments, and host path mounts Audits container and pod configuration for escape-enabling misconfiguration using the
using the kubernetes Python client. Identifies CVE-2022-0492 style escapes via cgroup Kubernetes Python client - privileged flags, dangerous capability grants, host path mounts,
abuse. Use when auditing container security posture or investigating escape attempts. shared namespaces, and CVE-2022-0492 style cgroup abuse. Use when sweeping a cluster for
workloads that could break out, producing a posture report, or checking configuration before
enforcement is switched on. Keywords: privileged, hostPath, hostPID, capabilities,
CVE-2022-0492, cgroup, kubernetes python client, posture audit. Do not use for runtime
syscall-based detection - use detecting-container-escape-attempts.
' '
domain: cybersecurity domain: cybersecurity
@@ -1,10 +1,13 @@
--- ---
name: performing-container-security-scanning-with-trivy name: performing-container-security-scanning-with-trivy
description: Scan container images, filesystems, Git repositories, and Kubernetes manifests description: >-
for OS and language-dependency vulnerabilities, IaC misconfigurations, exposed secrets, Runs Trivy across every target type it supports - container images, filesystems, Git
and license issues using Aqua Security's Trivy, generating CycloneDX/SPDX SBOMs. Use repositories, and Kubernetes clusters - for OS and dependency vulnerabilities, IaC
when integrating vulnerability scanning into CI/CD pipelines, deploying the Trivy misconfiguration, exposed secrets, and licences, generating CycloneDX or SPDX SBOMs. Use
Kubernetes operator, or triaging scan results for security operations. when integrating Trivy into CI/CD, deploying the Trivy Kubernetes operator, scanning
non-image targets, or triaging results at scale. Keywords: Trivy, trivy k8s, operator, SBOM,
CycloneDX, SPDX, misconfig, secret scanning. Do not use for a single Docker image scan - use
scanning-docker-images-with-trivy.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,11 +1,13 @@
--- ---
name: performing-docker-bench-security-assessment name: performing-docker-bench-security-assessment
description: Run Docker Bench for Security, the open-source CIS Docker Benchmark audit description: >-
script, to check host configuration, Docker daemon settings, container images, and Runs Docker Bench for Security, the open-source CIS Docker Benchmark audit script, across
runtime configurations, then interpret pass/fail/warn results and remediate common host configuration, daemon settings, images, and runtime configuration, then interprets
failures. Use when auditing Docker hosts for CIS Benchmark compliance, scheduling pass/fail/warn output and remediates the common failures. Use when auditing Docker hosts for
recurring container security assessments, or validating container runtime hardening CIS compliance, scheduling recurring container assessments, or validating runtime hardening
controls. controls after a change. Keywords: docker-bench-security, CIS Docker Benchmark, audit
script, pass fail warn, host configuration, remediation. Do not use for applying the daemon
hardening itself - use hardening-docker-daemon-configuration.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,14 @@
--- ---
name: performing-kubernetes-cis-benchmark-with-kube-bench name: performing-kubernetes-cis-benchmark-with-kube-bench
description: Audit Kubernetes cluster security posture against the CIS Kubernetes description: >-
Benchmark using kube-bench, running automated pass/fail/warn checks against the Turns kube-bench output into a finished CIS Kubernetes Benchmark audit: interpreting
control plane, etcd, worker nodes, and RBAC/policy configuration. Use when performing PASS/FAIL/WARN per control, judging which failures are genuine on a managed cluster, writing
compliance audits, cluster hardening reviews, or scheduled security assessments remediation, and packaging evidence for SOC 2 or PCI DSS. Use when conducting a scheduled
of a Kubernetes environment. compliance audit, triaging kube-bench results, deciding which controls are not applicable on
EKS, GKE, or AKS, or producing hardening evidence for an auditor. Keywords: CIS Kubernetes
Benchmark, control plane, remediation, compliance evidence, SOC 2, PCI DSS, managed cluster
exception. Do not use for installing and running the tool - use
benchmarking-kubernetes-with-kube-bench.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,13 @@
--- ---
name: performing-kubernetes-etcd-security-assessment name: performing-kubernetes-etcd-security-assessment
description: Assess the security posture of Kubernetes etcd clusters by evaluating description: >-
encryption at rest, TLS transport configuration, access controls, backup encryption, Assesses the security posture of the etcd cluster backing Kubernetes: encryption at rest,
and network isolation for the cluster's backing key-value store. Use when auditing TLS peer and client transport, access control, backup encryption, and network isolation. Use
or hardening a Kubernetes control plane, since etcd holds Secrets, RBAC policies, when auditing or hardening a control plane, reviewing whether Secrets are encrypted at rest,
and ConfigMaps in plaintext by default and is a high-value target if left unassessed. or protecting etcd backups, since etcd stores Secrets, RBAC policy, and ConfigMaps in
plaintext by default. Keywords: etcd, EncryptionConfiguration, encryption at rest, peer TLS,
snapshot, backup, control plane. Do not use for broad cluster-wide CIS checks - use
performing-kubernetes-cis-benchmark-with-kube-bench.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,13 @@
--- ---
name: performing-kubernetes-penetration-testing name: performing-kubernetes-penetration-testing
description: Systematically evaluate Kubernetes cluster security by simulating attacker description: >-
techniques against the API server, kubelet, etcd, pods, RBAC, network policies, and Evaluates Kubernetes cluster security by actively simulating attacker techniques against the
secrets, using tools like kube-hunter, Kubescape, peirates, and manual kubectl exploitation API server, kubelet, etcd, pods, RBAC, network policy, and secrets, using kube-hunter,
to identify misconfigurations leading to cluster compromise. Use for authorized Kubescape, peirates, and manual kubectl exploitation to find paths to cluster compromise.
penetration tests or hands-on validation of Kubernetes security controls. Use for an authorized penetration test or hands-on validation that controls actually stop an
attacker. Keywords: kube-hunter, Kubescape, peirates, kubelet 10250, anonymous auth, token
theft, lateral movement, cluster takeover. Do not use for a configuration-only compliance
audit - use performing-kubernetes-cis-benchmark-with-kube-bench.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,10 +1,12 @@
--- ---
name: scanning-container-images-with-grype name: scanning-container-images-with-grype
description: Scans container images, filesystems, and SBOMs for known CVEs using Anchore description: >-
Grype, matching Syft-generated SBOM packages against NVD, GitHub Advisories, and Scans container images, filesystems, and SBOMs for known CVEs with Anchore Grype, matching
OS-specific vulnerability feeds with configurable severity thresholds. Use when running Syft-generated SBOM packages against NVD, GitHub Advisories, and OS-specific feeds with
a security assessment or incident-response check that requires scanning container configurable severity thresholds and failure gates. Use when Grype or Syft is the chosen
images for known vulnerabilities with Grype. toolchain, when scanning an existing SBOM rather than an image, or when gating a build on
severity. Keywords: Grype, Syft, SBOM, NVD, GitHub Advisory, --fail-on, severity threshold.
Do not use when the toolchain is Trivy - use scanning-docker-images-with-trivy.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,11 +1,14 @@
--- ---
name: scanning-docker-images-with-trivy name: scanning-docker-images-with-trivy
description: Scans Docker container images with Trivy, Aqua Security's open-source description: >-
scanner, to detect vulnerabilities in OS packages and language-specific dependencies, Scans a Docker image with Trivy for vulnerabilities in OS packages and language
misconfigurations, exposed secrets, and license violations, outputting results in dependencies, misconfiguration, exposed secrets, and licence violations, emitting SARIF,
formats like SARIF, CycloneDX, or SPDX. Use when assessing, auditing, or scheduling CycloneDX, or SPDX output. Use when scanning or gating a specific image, wiring an image
a security scan of Docker images, including as part of CI/CD or incident-response scan into CI/CD, or checking an image during an incident investigation. Keywords: Trivy,
investigations. image scan, --severity, --exit-code, SARIF, ignore file, .trivyignore. Do not use for
cluster-wide scanning or non-image targets - use
performing-container-security-scanning-with-trivy; when the toolchain is Grype use
scanning-container-images-with-grype.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,8 +1,13 @@
--- ---
name: scanning-kubernetes-manifests-with-kubesec name: scanning-kubernetes-manifests-with-kubesec
description: Perform security risk analysis on Kubernetes resource manifests using description: >-
Kubesec to identify misconfigurations, privilege escalation risks, and deviations Scores Kubernetes resource manifests with Kubesec to flag misconfiguration and
from security best practices. privilege-escalation risk before deployment, mapping each finding back to the
securityContext change that fixes it. Use when gating manifests in CI, reviewing YAML or a
rendered chart before it reaches a cluster, or explaining why a manifest scored negatively.
Keywords: Kubesec, manifest score, securityContext, readOnlyRootFilesystem, runAsNonRoot, CI
gate. Do not use for scanning built images for CVEs - use scanning-docker-images-with-trivy;
for admission-time enforcement use implementing-opa-gatekeeper-for-policy-enforcement.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,11 +1,14 @@
--- ---
name: securing-container-registry-with-harbor name: securing-container-registry-with-harbor
description: Configures the Harbor open-source container registry's security features description: >-
— integrated Trivy vulnerability scanning, Notary/Cosign image signing and content Configures the security features of the Harbor open-source container registry - integrated
trust policies, project-level RBAC, immutable tag retention rules, and OIDC authentication Trivy scanning, Cosign and Notary content trust policies, project-level RBAC, immutable tag
to enforce image provenance and block vulnerable image deployment. Use when deploying and retention rules, and OIDC authentication - to enforce provenance and block deployment of
or hardening a Harbor registry, or when access control and compliance requirements vulnerable images. Use when deploying or hardening Harbor, or when compliance requires that
call for signed, scanned images. only signed and scanned images can be pulled. Keywords: Harbor, project policy, content
trust, immutable tag, retention, robot account, OIDC, replication. Do not use for signing
images with Cosign outside a registry - use
implementing-image-provenance-verification-with-cosign.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags:
@@ -1,11 +1,13 @@
--- ---
name: securing-helm-chart-deployments name: securing-helm-chart-deployments
description: Secures Helm chart deployments by verifying chart signatures and provenance, description: >-
rendering and scanning templates for misconfigurations with helm lint, enforcing Secures Helm chart deployments by verifying chart signatures and provenance, rendering and
pod security contexts in values.yaml, managing secrets via external stores instead linting templates for misconfiguration, enforcing pod security contexts through values.yaml,
of Helm values, and scoping RBAC for Helm operations in a CI/CD pipeline. Use when moving secrets into an external store instead of Helm values, and scoping RBAC for Helm
deploying Helm charts to Kubernetes or when a security review of chart provenance, operations in CI/CD. Use when deploying charts to Kubernetes or reviewing chart provenance,
templates, or release RBAC is needed. templates, or release RBAC. Keywords: Helm, provenance file, helm verify, helm lint,
values.yaml, Tiller-less, release RBAC, external secrets. Do not use for scanning the
rendered manifests themselves - use scanning-kubernetes-manifests-with-kubesec.
domain: cybersecurity domain: cybersecurity
subdomain: container-security subdomain: container-security
tags: tags: