mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-08-28 20:29:40 +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:
@@ -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:
|
||||||
|
|||||||
@@ -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:
|
||||||
|
|||||||
Reference in New Issue
Block a user