[REVIEW] container-security: add admission enforcement and policy-exception evidence gates

[briefsmith-lab]

Skill Being Reviewed

Skill name: container-security
Skill path: skills/cloud/container-security/

False Positive Analysis

Benign code that triggers a false positive:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: debug-toolbox
  namespace: dev-tools
spec:
  template:
    spec:
      containers:
        - name: toolbox
          image: cgr.dev/chainguard/wolfi-base:latest
          securityContext:
            runAsUser: 0
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

apiVersion: v1
kind: Namespace
metadata:
  name: dev-tools
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Why this is a false positive:
The current severity table treats running as root as High in broad terms. That is usually right for production application workloads, but the review process does not first require environment and admission-mode evidence. A root debug toolbox in a non-production namespace with Baseline enforcement, no privilege escalation, all capabilities dropped, and restricted audit/warn signals should be classified differently from a production app pod running as root with no admission controls. The finding should still be recorded, but severity should depend on namespace sensitivity, Pod Security Admission mode, compensating controls, and whether the policy is enforce/audit/warn only.

Coverage Gaps

Missed variant 1:

apiVersion: v1
kind: Namespace
metadata:
  name: payments-prod
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
    # missing enforce label, so restricted is advisory only

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
  namespace: payments-prod
spec:
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/payments-api:v1.2.3
          securityContext:
            allowPrivilegeEscalation: true

Why it should be caught:
The skill checks Pod Security Standards, but it does not require verifying whether the policy is actually enforced at namespace admission time. A namespace with only audit and warn labels can still admit noncompliant pods. For production namespaces, missing pod-security.kubernetes.io/enforce: restricted or an equivalent Gatekeeper/Kyverno enforcement policy should be a distinct finding, not just a workload-level hardening note.

Missed variant 2:

apiVersion: kyverno.io/v2
kind: PolicyException
metadata:
  name: allow-privileged-build-runner
  namespace: ci
spec:
  exceptions:
    - policyName: restrict-privileged-containers
      ruleNames:
        - privileged-containers
  match:
    any:
      - resources:
          kinds: [Pod]
          names: ["*"]

Why it should be caught:
The skill mentions OPA/Gatekeeper and Pod Security Standards, but it does not require reviewing policy exceptions, their scope, owner, ticket, expiry, or blast radius. A broad exception can silently bypass otherwise strong admission policy. This is especially important for CI/build namespaces where privileged runners are common and can become a cluster escape path.

Edge Cases

• Some clusters use Pod Security Admission labels only for audit/warn during migration. That is acceptable during a time-boxed rollout, but the review should require a target enforcement date and tracking evidence.
• Gatekeeper/Kyverno policies can be present but not equivalent to Kubernetes Restricted PSS. Reviewers should map policy coverage to concrete controls such as privileged, hostPID, hostNetwork, capabilities, seccomp, and allowPrivilegeEscalation.
• Policy exceptions can be safe when tightly scoped to a service account, namespace, image, and expiration date. The dangerous case is wildcard resource matching, no owner, or no expiry.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add admission enforcement and exception governance gates before final Pod Security severity classification.

Suggested additions:

K8S-ADMISSION-01: For each namespace, record Pod Security Admission labels: enforce, audit, warn, and their versions.
K8S-ADMISSION-02: Classify production/high-sensitivity namespaces without enforce=restricted or equivalent policy as High unless a documented migration plan exists.
K8S-ADMISSION-03: If Gatekeeper/Kyverno is used instead of PSA, map enforced policies to Restricted PSS controls and record validation evidence.
K8S-ADMISSION-04: Review policy exceptions/exclusions for scope, owner, ticket, expiry, and wildcard matches.
K8S-ADMISSION-05: Treat audit/warn-only controls as visibility, not prevention, in the final severity calculation.

Comparison to Other Tools

Tool	Catches this?	Notes
kubectl / API server inspection	Partial	Can show namespace labels and admission configuration, but the skill must require collecting them.
Kyverno CLI	Partial	Can test policy results against manifests, but exceptions and enforcement mode still need governance review.
OPA Gatekeeper	Partial	Constraint templates can enforce controls, but reviewers must inspect exclusions and enforcement actions.
kube-score / kube-linter	Partial	Good at workload manifest findings, weaker at cluster admission mode and exception lifecycle evidence.

Overall Assessment

Strengths:
The skill already covers the right container domains: Dockerfiles, Kubernetes manifests, Pod Security Standards, RBAC, NetworkPolicy, secrets, runtime hardening, and common pitfalls around init/sidecar/ephemeral containers.

Needs improvement:
It should distinguish manifest-level hardening from admission-time enforcement. A cluster can have strong-looking policies that only warn, or a workload can look noncompliant but be contained in a lower-sensitivity namespace with compensating controls. Without admission labels, Gatekeeper/Kyverno enforcement mode, and exception governance, severity can be either overstated or understated.

Priority recommendations:

1. Add a namespace/admission-control evidence table to the output format.
2. Require exception/exclusion review for Kyverno, Gatekeeper, and PSA migration cases.
3. Treat audit/warn-only Pod Security controls as non-blocking visibility, not enforcement, when assigning severity.

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: PayPal