Zero-Static-Key Container Attestation via Sigstore Fulcio-Rekor Admission Policy

Enforces zero-static-key container provenance verification at the Kubernetes admission layer using short-lived Fulcio X.509 OIDC certificates and append-only Rekor transparency log proofs. Prohibits static long-lived asymmetric keys, unpinned OIDC issuer identities, and admission policies that fail open or skip Rekor inclusion verification (SET/SCT validation). Mandates strict validation of cryptographic subject alternative names (SAN), issuer URI claims, and in-toto provenance attestations before workload scheduling.

--- description: Zero-Static-Key Container Attestation via Sigstore Fulcio-Rekor Admission Policy - Enforces zero-static-key container provenance verification at the Kubernetes admission layer using short-lived Fulcio X.509 OIDC certificates and append-only Rekor transparency log proofs. Prohibits static long-lived asymmetric keys, unpinned OIDC issuer identities, and admission policies that fail open or skip Rekor inclusion verification (SET/SCT validation). Mandates strict validation of cryptographic subject alternative names (SAN), issuer URI claims, and in-toto provenance attestations before workload scheduling. globs: policies/**/*.{yaml,yml}, k8s/**/*.{yaml,yml}, src/**/*.{ts,go,py}, helm/**/*.{yaml,yml}, infra/**/*.{tf,hcl} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/sigstore-fulcio-rekor-ephemeral-attestation-admission-standard" --- # Zero-Static-Key Container Attestation via Sigstore Fulcio-Rekor Admission Policy > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Validating signatures using static public keys, unanchored OIDC issuers, or unverified Rekor transparency log entries in admission webhooks ## System Constraints You are a Principal Security Architect enforcing the Sigstore Fulcio-Rekor Ephemeral Attestation Admission Standard. Enforce keyless cryptographic provenance, strict OIDC identity attestation, and mandatory transparency log verification for all container workloads prior to cluster execution. ## Strict Guidelines - Engineers MUST ALWAYS enforce keyless OIDC-based signature and attestation verification, requiring both exact OIDC issuer URLs (e.g., https://token.actions.githubusercontent.com) and subject identity SAN regular expressions. - Engineers MUST NOT configure static PGP, RSA, or ECDSA public keys for production admission control verification. - Admission controllers MUST verify Signed Entry Timestamps (SET) and cryptographically validate Rekor transparency log inclusion proofs before granting admission. - Engineers MUST configure Kyverno ClusterPolicies or PolicyController ClusterImagePolicies with failurePolicy set to Fail, never Ignore or permissive dry-run in production clusters. - Policy definitions MUST validate Cosign in-toto provenance predicate layers (SLSA Provenance v0.2/v1.0) and confirm matching digest identifiers with the immutable SHA256 of the target image. ## Bad vs Good Implementations ### Kubernetes Admission Policy: Keyless Fulcio-Rekor Verification vs Static Public Key Anti-Pattern #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using static cryptographic public keys introduces key compromise, lack of revocation checking, operational burden of rotation, and completely bypasses Fulcio ephemeral OIDC identity chains and Rekor transparency log verification. ```yaml # ANTI-PATTERN: Verifies using long-lived static public key without transparency log guarantees apiVersion: policy.sigstore.dev/v1beta1 kind: ClusterImagePolicy metadata: name: verify-production-images spec: images: - glob: "registry.corp.internal/apps/**" authorities: - name: static-rsa-key key: data: | -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0CAQ0CA0IABM...STATIC-KEY-ROTATION-RISK... -----END PUBLIC KEY----- # Missing Rekor integration and OIDC identity enforcement mode: enforce ``` #### Production Standard (Correct) > **Standard**: Eliminates static key management entirely. Enforces that images are signed strictly via GitHub Actions OIDC issuing short-lived Fulcio certificates, recorded into the public Rekor transparency log, and accompanied by a SLSA provenance attestation matching the branch reference. ```yaml # PRODUCTION STANDARD: Keyless verification via Fulcio short-lived certs and Rekor transparency log apiVersion: policy.sigstore.dev/v1beta1 kind: ClusterImagePolicy metadata: name: verify-production-images spec: images: - glob: "registry.corp.internal/apps/**" authorities: - name: ephemeral-oidc-fulcio-rekor keyless: url: "https://fulcio.sigstore.dev" identities: - issuer: "https://token.actions.githubusercontent.com" subjectRegExp: "^https://github.com/my-org/my-repo/\.github/workflows/.*@refs/heads/main$" ctlog: url: "https://rekor.sigstore.dev" attestations: - name: slsa-attestation predicateType: "https://slsa.dev/provenance/v0.2" mode: enforce ``` ### Admission Webhook Verification: Node.js/TypeScript In-Memory Sigstore Verification Handler #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Fails to enforce cryptographic attestation verification, ignoring Fulcio root certs, Rekor inclusion validation, and subject SAN identity bounds, allowing unsigned or spoofed containers to schedule. ```typescript // ANTI-PATTERN: Naive admission check accepting self-signed or unverified signatures import { Request, Response } from 'express'; export async function admissionHook(req: Request, res: Response): Promise<void> { const pod = req.body.request.object; const container = pod.spec.containers[0]; // Flaw: Bypassing Rekor transparency log verification and checking only raw signature existence if (!container.image.includes('@sha256:')) { res.status(400).json({ response: { allowed: false, status: { message: 'Must use digest' } } }); return; } // Permissive failure: returning allowed without cryptographically validating Fulcio SAN or Rekor res.status(200).json({ response: { allowed: true } }); } ``` #### Production Standard (Correct) > **Standard**: Validates the image signature strictly against the official Sigstore trust root, demanding verification of the short-lived Fulcio certificate's SAN OIDC claim and Rekor transparency log inclusion proof. ```typescript // PRODUCTION STANDARD: Comprehensive Sigstore verification enforcing OIDC identity and Rekor bundle import { Request, Response } from 'express'; import { sigstore } from 'sigstore'; interface AdmissionRequestBody { request: { uid: string; object: { spec: { containers: Array<{ image: string }> }; }; }; } export async function admissionHook(req: Request<{}, {}, AdmissionRequestBody>, res: Response): Promise<void> { const { uid, object: pod } = req.body.request; const targetImage = pod.spec.containers[0]?.image; if (!targetImage || !targetImage.includes('@sha256:')) { res.status(200).json({ response: { uid, allowed: false, status: { message: 'Image must use immutable sha256 digest' } } }); return; } try { // Mandate bundle verification with Fulcio issuer & Rekor inclusion await sigstore.verify(targetImage, { certificateIssuer: 'https://token.actions.githubusercontent.com', certificateIdentityURI: 'https://github.com/my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main', rekorTlogRequired: true, tlogThreshold: 1 }); res.status(200).json({ response: { uid, allowed: true } }); } catch (error) { res.status(200).json({ response: { uid, allowed: false, status: { message: `Sigstore admission rejected: ${(error as Error).message}` } } }); } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Zero-Static-Key Container Attestation via Sigstore Fulcio-Rekor Admission Policy

Zero-Static-Key Container Attestation via Sigstore Fulcio-Rekor Admission Policy defines an industrial-grade behavioral standard for security engineering. Enforces zero-static-key container provenance verification at the Kubernetes admission layer using short-lived Fulcio X.509 OIDC certificates and append-only Rekor transparency log proofs. Prohibits static long-lived asymmetric keys, unpinned OIDC issuer identities, and admission policies that fail open or skip Rekor inclusion verification (SET/SCT validation). Mandates strict validation of cryptographic subject alternative names (SAN), issuer URI claims, and in-toto provenance attestations before workload scheduling. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Validating signatures using static public keys, unanchored OIDC issuers, or unverified Rekor transparency log entries in admission webhooks Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Validating signatures using static public keys, unanchored OIDC issuers, or unverified Rekor transparency log entries in admission webhooks	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS enforce keyless OIDC-based signature and attestation verification, requiring both exact OIDC issuer URLs (e.g., https

Engineers MUST ALWAYS enforce keyless OIDC-based signature and attestation verification, requiring both exact OIDC issuer URLs (e.g., https://token.actions.githubusercontent.com) and subject identity SAN regular expressions.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.