mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-08-28 12:19:41 +03:00
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
@@ -1,9 +1,13 @@
|
||||
---
|
||||
name: analyzing-kubernetes-audit-logs
|
||||
description: 'Parses Kubernetes API server audit logs (JSON lines) to detect exec-into-pod,
|
||||
secret access, RBAC modifications, privileged pod creation, and anonymous API access.
|
||||
Builds threat detection rules from audit event patterns. Use when investigating
|
||||
Kubernetes cluster compromise or building k8s-specific SIEM detection rules.
|
||||
description: >-
|
||||
Parses Kubernetes API server audit logs (JSON lines) to detect exec-into-pod, secret access,
|
||||
RBAC modifications, privileged pod creation, and anonymous API access, and builds SIEM
|
||||
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
|
||||
|
||||
@@ -1,6 +1,13 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,6 +1,14 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,6 +1,14 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,6 +1,15 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,6 +1,14 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,6 +1,13 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
name: detecting-privilege-escalation-in-kubernetes-pods
|
||||
description: Detect and prevent privilege escalation in Kubernetes pods by combining
|
||||
admission control (OPA policies), runtime monitoring (Falco), and audit log
|
||||
analysis of security contexts, Linux capabilities, and syscall patterns. Use
|
||||
when hardening pod security policies, investigating a pod running as root or
|
||||
privileged, or hunting for containers escaping their intended scope.
|
||||
description: >-
|
||||
Detects and prevents privilege escalation inside Kubernetes pods by combining admission
|
||||
control (OPA policies), runtime monitoring (Falco), and audit log analysis of security
|
||||
contexts, Linux capabilities, and syscall patterns. Use when investigating a pod running as
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,6 +1,13 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,12 +1,13 @@
|
||||
---
|
||||
name: hardening-docker-containers-for-production
|
||||
description: >
|
||||
Harden Dockerfiles, images, and container runtime settings against the CIS
|
||||
Docker Benchmark v1.8.0: non-root users, dropped capabilities, read-only
|
||||
rootfs, seccomp/AppArmor, and minimal multi-stage images, validated with
|
||||
docker-bench-security, Hadolint, and Dockle. Use when preparing a container
|
||||
or Dockerfile for production, or auditing images/runtime configs against
|
||||
CIS Docker controls.
|
||||
description: >-
|
||||
Hardens Dockerfiles, images, and per-container runtime settings against the CIS Docker
|
||||
Benchmark v1.8.0: non-root users, dropped capabilities, read-only root filesystem, seccomp
|
||||
and AppArmor profiles, and minimal multi-stage builds, validated with docker-bench-security,
|
||||
Hadolint, and Dockle. Use when preparing a container or Dockerfile for production, or
|
||||
auditing images and runtime flags against CIS Docker controls. Keywords: Dockerfile, USER,
|
||||
--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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,6 +1,13 @@
|
||||
---
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
name: implementing-container-image-minimal-base-with-distroless
|
||||
description: Reduces container attack surface by building application images on Google
|
||||
distroless base images that contain only the app runtime with no shell, package
|
||||
manager, or OS utilities, using multi-stage Docker build patterns and debug/scanning
|
||||
techniques for distroless containers. Use when hardening container images, cutting
|
||||
attack surface in a container security architecture, or responding to a security
|
||||
assessment that flags bloated base images.
|
||||
description: >-
|
||||
Reduces container attack surface by building application images on Google distroless base
|
||||
images that ship only the application runtime - no shell, package manager, or OS utilities -
|
||||
using multi-stage build patterns plus debugging and scanning techniques adapted to
|
||||
distroless. Use when hardening container images, cutting attack surface in a container
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,14 @@
|
||||
---
|
||||
name: implementing-container-network-policies-with-calico
|
||||
description: Enforces Kubernetes network segmentation by creating and auditing Calico
|
||||
NetworkPolicy and GlobalNetworkPolicy resources via calicoctl and the Kubernetes
|
||||
API, controlling pod-to-pod traffic, namespace isolation, egress restrictions, and
|
||||
DNS-based rules. Use when implementing zero-trust microsegmentation in a Calico-CNI
|
||||
cluster or hardening pod-to-pod and egress traffic controls.
|
||||
description: >-
|
||||
Uses Calico's own policy CRDs beyond the upstream Kubernetes API - GlobalNetworkPolicy,
|
||||
HostEndpoint, NetworkSet, policy tiers, and DNS-based egress rules - applied and audited
|
||||
with calicoctl. Use when a policy must span namespaces or protect the host itself, when
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
name: implementing-image-provenance-verification-with-cosign
|
||||
description: Signs and verifies container image provenance using Sigstore Cosign,
|
||||
covering key-based and keyless OIDC-based signing (Fulcio, Rekor transparency log),
|
||||
SLSA attestations, and enforcing signature verification via Kubernetes admission
|
||||
control. Use when signing container images for supply chain security, setting
|
||||
up keyless OIDC signing, attaching attestations, or enforcing verified-image-only
|
||||
policies at admission in a Kubernetes cluster.
|
||||
description: >-
|
||||
Signs and verifies container image provenance with Sigstore Cosign, covering key-based and
|
||||
keyless OIDC signing (Fulcio, Rekor transparency log), SLSA attestations, and enforcing
|
||||
signature verification through Kubernetes admission control. Use when signing images for
|
||||
supply chain security, setting up keyless OIDC signing, attaching attestations, or enforcing
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,12 +1,15 @@
|
||||
---
|
||||
name: implementing-kubernetes-network-policy-with-calico
|
||||
description: >-
|
||||
Implements Kubernetes network segmentation using Calico's Kubernetes
|
||||
NetworkPolicy and GlobalNetworkPolicy resources, including default-deny rules,
|
||||
policy ordering, and service-account-based selectors for zero-trust
|
||||
pod-to-pod communication. Use when installing Calico CNI and writing or
|
||||
auditing network policies to restrict east-west traffic within a Kubernetes
|
||||
cluster.
|
||||
Installs Calico as the cluster CNI and writes standard Kubernetes NetworkPolicy under it,
|
||||
covering default-deny baselines, policy ordering and precedence, service-account-based
|
||||
selectors, and verifying that policy is genuinely being enforced. Use when adopting Calico
|
||||
as the enforcement CNI, establishing a default-deny baseline, or debugging why a
|
||||
NetworkPolicy is not taking effect under Calico. Keywords: Calico CNI, NetworkPolicy,
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,12 +1,17 @@
|
||||
---
|
||||
name: implementing-kubernetes-pod-security-standards
|
||||
description: >-
|
||||
Configures Kubernetes Pod Security Standards (Privileged, Baseline, Restricted)
|
||||
enforced via the built-in Pod Security Admission (PSA) controller (Kubernetes
|
||||
1.25+), including namespace labeling and enforce/audit/warn modes. Use when
|
||||
hardening pod configurations against privilege escalation, migrating off
|
||||
deprecated PodSecurityPolicy, or setting namespace-level pod security
|
||||
enforcement.
|
||||
Chooses and applies the correct Kubernetes Pod Security Standard (Privileged,
|
||||
Baseline, Restricted) for a workload: what each profile forbids, how to map
|
||||
existing workloads to a profile, which securityContext fields must change, and
|
||||
how to plan a PodSecurityPolicy-to-PSS migration without breaking running pods.
|
||||
Use when deciding which pod security profile a namespace or workload should run
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
@@ -38,10 +43,15 @@ Pod Security Standards (PSS) define three levels of security policies -- Privile
|
||||
|
||||
## When to Use
|
||||
|
||||
- When deploying or configuring implementing kubernetes pod security standards capabilities in your environment
|
||||
- When establishing security controls aligned to compliance requirements
|
||||
- When building or improving security architecture for this domain
|
||||
- When conducting security assessments that require this implementation
|
||||
- Deciding whether a namespace or workload belongs at Privileged, Baseline, or Restricted
|
||||
- Auditing which existing workloads would be rejected if Restricted were enforced today
|
||||
- Translating a "must meet Restricted" requirement into concrete `securityContext` changes
|
||||
- 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
|
||||
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
name: implementing-network-policies-for-kubernetes
|
||||
description: Writes Kubernetes NetworkPolicy YAML (default-deny-all, DNS egress, namespace/pod
|
||||
selector rules) enforced via CNI plugins like Calico or Cilium to control ingress
|
||||
and egress traffic between pods, namespaces, and external endpoints. Use when
|
||||
implementing zero-trust microsegmentation inside a Kubernetes cluster to prevent
|
||||
lateral movement between workloads or namespaces.
|
||||
description: >-
|
||||
Writes portable upstream Kubernetes NetworkPolicy YAML - default-deny-all, DNS egress,
|
||||
namespace and pod selector rules - that works on any conformant CNI such as Calico or
|
||||
Cilium. Use when segmentation must stay CNI-portable, introducing a default-deny posture, or
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,14 @@
|
||||
---
|
||||
name: implementing-opa-gatekeeper-for-policy-enforcement
|
||||
description: Deploys OPA Gatekeeper via Helm as a Kubernetes admission controller and writes
|
||||
ConstraintTemplates with Rego rules plus instantiated Constraints to validate,
|
||||
mutate, or deny resource requests at admission time. Use when enforcing policy-as-code
|
||||
admission control in a Kubernetes cluster (v1.24+), such as blocking non-compliant
|
||||
workloads before they are scheduled.
|
||||
description: >-
|
||||
Deploys OPA Gatekeeper via Helm as a Kubernetes admission controller and writes
|
||||
ConstraintTemplates with Rego plus instantiated Constraints to validate, mutate, or deny
|
||||
resource requests at admission time. Use when enforcing custom policy-as-code at admission
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,17 @@
|
||||
---
|
||||
name: implementing-pod-security-admission-controller
|
||||
description: Implement Kubernetes Pod Security Admission (PSA), the built-in admission
|
||||
controller stable since v1.25, to enforce Privileged, Baseline, and Restricted
|
||||
Pod Security Standards at the namespace level with enforce, audit, and warn modes,
|
||||
replacing the deprecated PodSecurityPolicy. Use when hardening Kubernetes namespaces,
|
||||
migrating off PodSecurityPolicy, or enforcing pod-level security baselines.
|
||||
description: >-
|
||||
Configures and operates the Kubernetes Pod Security Admission (PSA) controller
|
||||
that enforces Pod Security Standards: namespace enforce/audit/warn labels,
|
||||
cluster-wide defaults via AdmissionConfiguration, exemptions for usernames,
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
@@ -37,10 +44,16 @@ Pod Security Admission (PSA) is a built-in Kubernetes admission controller (stab
|
||||
|
||||
## When to Use
|
||||
|
||||
- When deploying or configuring implementing pod security admission controller capabilities in your environment
|
||||
- When establishing security controls aligned to compliance requirements
|
||||
- When building or improving security architecture for this domain
|
||||
- When conducting security assessments that require this implementation
|
||||
- Wiring PSA up on a cluster for the first time
|
||||
- Setting cluster-wide default enforcement via `AdmissionConfiguration`
|
||||
- Exempting system namespaces, service accounts, or runtime classes from enforcement
|
||||
- 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
|
||||
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
name: implementing-rbac-hardening-for-kubernetes
|
||||
description: Harden Kubernetes RBAC by implementing least-privilege Roles and ClusterRoles,
|
||||
auditing RoleBindings, eliminating cluster-admin sprawl, separating service accounts,
|
||||
and integrating external identity providers (OIDC). Use when reviewing or tightening
|
||||
Kubernetes access control, removing excessive ClusterRoleBindings, or hardening
|
||||
service-account permissions against privilege escalation and lateral movement.
|
||||
description: >-
|
||||
Hardens Kubernetes RBAC by designing least-privilege Roles and ClusterRoles, auditing
|
||||
RoleBindings, eliminating cluster-admin sprawl, separating service accounts, and integrating
|
||||
an external OIDC identity provider. Use when tightening cluster access control, removing
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
name: implementing-runtime-security-with-tetragon
|
||||
description: Implement eBPF-based runtime security observability and enforcement in
|
||||
Kubernetes clusters using Cilium Tetragon, monitoring process execution, file access,
|
||||
network connections, and syscalls at the kernel level. Use when deploying Tetragon
|
||||
to detect or block dangerous syscalls (ptrace, mount, unshare), enforce kernel-level
|
||||
Kubernetes security policy, or add low-overhead runtime threat detection to a cluster.
|
||||
description: >-
|
||||
Implements eBPF-based runtime observability and in-kernel enforcement in Kubernetes with
|
||||
Cilium Tetragon, monitoring process execution, file access, network connections, and
|
||||
syscalls, and blocking dangerous calls at the kernel level. Use when deploying Tetragon to
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,12 +1,13 @@
|
||||
---
|
||||
name: implementing-supply-chain-security-with-in-toto
|
||||
description: Implement software supply chain integrity verification for container
|
||||
builds using the in-toto framework, covering signing-key generation, defining a
|
||||
supply chain layout, recording pipeline steps as signed link metadata, verifying
|
||||
before deployment, Kubernetes admission control, and SLSA integration. Use when
|
||||
generating in-toto attestations for CI/CD pipeline steps, verifying that a container
|
||||
image followed an approved build process, or enforcing supply chain provenance
|
||||
at admission time.
|
||||
description: >-
|
||||
Implements supply chain integrity verification for container builds with the in-toto
|
||||
framework: generating signing keys, defining a supply chain layout, recording pipeline steps
|
||||
as signed link metadata, verifying before deployment, enforcing at Kubernetes admission, and
|
||||
integrating with SLSA. Use when attesting CI/CD pipeline steps, proving an image followed
|
||||
the approved build process, or enforcing provenance at admission. Keywords: in-toto, layout,
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,9 +1,13 @@
|
||||
---
|
||||
name: performing-container-escape-detection
|
||||
description: 'Detects container escape attempts by analyzing namespace configurations,
|
||||
privileged container checks, dangerous capability assignments, and host path mounts
|
||||
using the kubernetes Python client. Identifies CVE-2022-0492 style escapes via cgroup
|
||||
abuse. Use when auditing container security posture or investigating escape attempts.
|
||||
description: >-
|
||||
Audits container and pod configuration for escape-enabling misconfiguration using the
|
||||
Kubernetes Python client - privileged flags, dangerous capability grants, host path mounts,
|
||||
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
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
name: performing-container-security-scanning-with-trivy
|
||||
description: Scan container images, filesystems, Git repositories, and Kubernetes manifests
|
||||
for OS and language-dependency vulnerabilities, IaC misconfigurations, exposed secrets,
|
||||
and license issues using Aqua Security's Trivy, generating CycloneDX/SPDX SBOMs. Use
|
||||
when integrating vulnerability scanning into CI/CD pipelines, deploying the Trivy
|
||||
Kubernetes operator, or triaging scan results for security operations.
|
||||
description: >-
|
||||
Runs Trivy across every target type it supports - container images, filesystems, Git
|
||||
repositories, and Kubernetes clusters - for OS and dependency vulnerabilities, IaC
|
||||
misconfiguration, exposed secrets, and licences, generating CycloneDX or SPDX SBOMs. Use
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
name: performing-docker-bench-security-assessment
|
||||
description: Run Docker Bench for Security, the open-source CIS Docker Benchmark audit
|
||||
script, to check host configuration, Docker daemon settings, container images, and
|
||||
runtime configurations, then interpret pass/fail/warn results and remediate common
|
||||
failures. Use when auditing Docker hosts for CIS Benchmark compliance, scheduling
|
||||
recurring container security assessments, or validating container runtime hardening
|
||||
controls.
|
||||
description: >-
|
||||
Runs Docker Bench for Security, the open-source CIS Docker Benchmark audit script, across
|
||||
host configuration, daemon settings, images, and runtime configuration, then interprets
|
||||
pass/fail/warn output and remediates the common failures. Use when auditing Docker hosts for
|
||||
CIS compliance, scheduling recurring container assessments, or validating runtime hardening
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,14 @@
|
||||
---
|
||||
name: performing-kubernetes-cis-benchmark-with-kube-bench
|
||||
description: Audit Kubernetes cluster security posture against the CIS Kubernetes
|
||||
Benchmark using kube-bench, running automated pass/fail/warn checks against the
|
||||
control plane, etcd, worker nodes, and RBAC/policy configuration. Use when performing
|
||||
compliance audits, cluster hardening reviews, or scheduled security assessments
|
||||
of a Kubernetes environment.
|
||||
description: >-
|
||||
Turns kube-bench output into a finished CIS Kubernetes Benchmark audit: interpreting
|
||||
PASS/FAIL/WARN per control, judging which failures are genuine on a managed cluster, writing
|
||||
remediation, and packaging evidence for SOC 2 or PCI DSS. Use when conducting a scheduled
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
name: performing-kubernetes-etcd-security-assessment
|
||||
description: Assess the security posture of Kubernetes etcd clusters by evaluating
|
||||
encryption at rest, TLS transport configuration, access controls, backup encryption,
|
||||
and network isolation for the cluster's backing key-value store. Use when auditing
|
||||
or hardening a Kubernetes control plane, since etcd holds Secrets, RBAC policies,
|
||||
and ConfigMaps in plaintext by default and is a high-value target if left unassessed.
|
||||
description: >-
|
||||
Assesses the security posture of the etcd cluster backing Kubernetes: encryption at rest,
|
||||
TLS peer and client transport, access control, backup encryption, and network isolation. Use
|
||||
when auditing or hardening a control plane, reviewing whether Secrets are encrypted at rest,
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
---
|
||||
name: performing-kubernetes-penetration-testing
|
||||
description: Systematically evaluate Kubernetes cluster security by simulating attacker
|
||||
techniques against the API server, kubelet, etcd, pods, RBAC, network policies, and
|
||||
secrets, using tools like kube-hunter, Kubescape, peirates, and manual kubectl exploitation
|
||||
to identify misconfigurations leading to cluster compromise. Use for authorized
|
||||
penetration tests or hands-on validation of Kubernetes security controls.
|
||||
description: >-
|
||||
Evaluates Kubernetes cluster security by actively simulating attacker techniques against the
|
||||
API server, kubelet, etcd, pods, RBAC, network policy, and secrets, using kube-hunter,
|
||||
Kubescape, peirates, and manual kubectl exploitation to find paths to cluster compromise.
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,10 +1,12 @@
|
||||
---
|
||||
name: scanning-container-images-with-grype
|
||||
description: Scans container images, filesystems, and SBOMs for known CVEs using Anchore
|
||||
Grype, matching Syft-generated SBOM packages against NVD, GitHub Advisories, and
|
||||
OS-specific vulnerability feeds with configurable severity thresholds. Use when running
|
||||
a security assessment or incident-response check that requires scanning container
|
||||
images for known vulnerabilities with Grype.
|
||||
description: >-
|
||||
Scans container images, filesystems, and SBOMs for known CVEs with Anchore Grype, matching
|
||||
Syft-generated SBOM packages against NVD, GitHub Advisories, and OS-specific feeds with
|
||||
configurable severity thresholds and failure gates. Use when Grype or Syft is the chosen
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,11 +1,14 @@
|
||||
---
|
||||
name: scanning-docker-images-with-trivy
|
||||
description: Scans Docker container images with Trivy, Aqua Security's open-source
|
||||
scanner, to detect vulnerabilities in OS packages and language-specific dependencies,
|
||||
misconfigurations, exposed secrets, and license violations, outputting results in
|
||||
formats like SARIF, CycloneDX, or SPDX. Use when assessing, auditing, or scheduling
|
||||
a security scan of Docker images, including as part of CI/CD or incident-response
|
||||
investigations.
|
||||
description: >-
|
||||
Scans a Docker image with Trivy for vulnerabilities in OS packages and language
|
||||
dependencies, misconfiguration, exposed secrets, and licence violations, emitting SARIF,
|
||||
CycloneDX, or SPDX output. Use when scanning or gating a specific image, wiring an image
|
||||
scan into CI/CD, or checking an image during an incident investigation. Keywords: Trivy,
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,8 +1,13 @@
|
||||
---
|
||||
name: scanning-kubernetes-manifests-with-kubesec
|
||||
description: Perform security risk analysis on Kubernetes resource manifests using
|
||||
Kubesec to identify misconfigurations, privilege escalation risks, and deviations
|
||||
from security best practices.
|
||||
description: >-
|
||||
Scores Kubernetes resource manifests with Kubesec to flag misconfiguration and
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,11 +1,14 @@
|
||||
---
|
||||
name: securing-container-registry-with-harbor
|
||||
description: Configures the Harbor open-source container registry's security features
|
||||
— integrated Trivy vulnerability scanning, Notary/Cosign image signing and content
|
||||
trust policies, project-level RBAC, immutable tag retention rules, and OIDC authentication
|
||||
— to enforce image provenance and block vulnerable image deployment. Use when deploying
|
||||
or hardening a Harbor registry, or when access control and compliance requirements
|
||||
call for signed, scanned images.
|
||||
description: >-
|
||||
Configures the security features of the Harbor open-source container registry - integrated
|
||||
Trivy scanning, Cosign and Notary content trust policies, project-level RBAC, immutable tag
|
||||
and retention rules, and OIDC authentication - to enforce provenance and block deployment of
|
||||
vulnerable images. Use when deploying or hardening Harbor, or when compliance requires that
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
name: securing-helm-chart-deployments
|
||||
description: Secures Helm chart deployments by verifying chart signatures and provenance,
|
||||
rendering and scanning templates for misconfigurations with helm lint, enforcing
|
||||
pod security contexts in values.yaml, managing secrets via external stores instead
|
||||
of Helm values, and scoping RBAC for Helm operations in a CI/CD pipeline. Use when
|
||||
deploying Helm charts to Kubernetes or when a security review of chart provenance,
|
||||
templates, or release RBAC is needed.
|
||||
description: >-
|
||||
Secures Helm chart deployments by verifying chart signatures and provenance, rendering and
|
||||
linting templates for misconfiguration, enforcing pod security contexts through values.yaml,
|
||||
moving secrets into an external store instead of Helm values, and scoping RBAC for Helm
|
||||
operations in CI/CD. Use when deploying charts to Kubernetes or reviewing chart provenance,
|
||||
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
|
||||
subdomain: container-security
|
||||
tags:
|
||||
|
||||
Reference in New Issue
Block a user