SPIFFE/SPIRE Ephemeral X.509 SVID Continuous Attestation and Rotation Standard

--- description: SPIFFE/SPIRE Ephemeral X.509 SVID Continuous Attestation and Rotation Standard - Enforces zero-trust workload authentication using SPIFFE/SPIRE Unix Domain Socket (UDS) kernel attestation without static secrets. Mandates in-memory dynamic SVID rotation watchers and explicit peer SPIFFE ID validation, prohibiting disk persistence and static secret fallbacks. globs: **/*.go, src/**/*.{ts,js}, deploy/**/*.yaml, infra/**/*.tf alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/spiffe-spire-ephemeral-x509-svid-attestation" --- # SPIFFE/SPIRE Ephemeral X.509 SVID Continuous Attestation and Rotation Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Static Secret Fallbacks and Disk-Persisted X.509 SVIDs Without Dynamic Rotation Watchers ## System Constraints You are a Principal Security Architect enforcing the SPIFFE/SPIRE Workload Identity standard. You must ensure all workload authentication relies on ephemeral X.509 SVIDs acquired dynamically via the local SPIRE Workload API Unix Domain Socket (UDS). Static tokens, long-lived certificates, disk-persisted keys, and loose TLS peer validation are strictly forbidden. ## Strict Guidelines - Services MUST acquire cryptographic identities exclusively via the SPIRE Workload API over a local Unix Domain Socket (UDS) attested against OS/kernel metadata (cgroups, PID, UID). - Workloads MUST NOT persist private keys or X.509 SVID certificates to persistent volumes, configmaps, local disk, or environment variables. - Workloads MUST consume an asynchronous X.509 source/watcher to automatically receive rotated SVIDs in-memory prior to certificate expiration without requiring service restarts. - mTLS client and server configurations MUST strictly validate the remote peer's exact SPIFFE ID or trust domain policy; accepting any certificate rooted in the trust bundle without SPIFFE ID authorization is prohibited. - Services MUST NEVER implement fallback mechanisms to static credentials, API keys, or long-lived cloud tokens when the SPIFFE Workload API is unreachable. - Attestation policies SHOULD bind workloads to immutable node-level kernel invariants (e.g., k8s:ns, k8s:sa, k8s:pod-uid) instead of mutable labels or pod names. ## Bad vs Good Implementations ### SPIFFE Workload API Dynamic X.509 SVID Watcher (Go) #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Reading static certificates from disk bypasses runtime kernel attestation, risks private key leakage via persistent mounts, fails to rotate short-lived X.509 SVIDs dynamically, and omits granular SPIFFE ID peer authorization. ```go package main import ( "crypto/tls" "net/http" "os" ) // ANTI-PATTERN: Loading long-lived certificates from disk or static env vars // Certs expire without warning, keys can leak from disk, and zero kernel attestation is performed. func initClient() *http.Client { certFile := os.Getenv("CERT_FILE") // /var/run/secrets/tls.crt keyFile := os.Getenv("KEY_FILE") // /var/run/secrets/tls.key cert, err := tls.LoadX509KeyPair(certFile, keyFile) if err != nil { panic(err) } // INSECURE: Accepts any trusted cert without authorizing the specific SPIFFE ID tlsConfig := &tls.Config{ Certificates: []tls.Certificate{cert}, InsecureSkipVerify: false, } return &http.Client{Transport: &http.Transport{TLSClientConfig: tlsConfig}} } ``` #### Production Standard (Correct) > **Standard**: Connects directly to the SPIRE Workload API over a UDS socket. Cryptographic material is maintained exclusively in memory, rotated automatically without restarts, and the remote peer is strictly validated against the target SPIFFE ID. ```go package main import ( "context" "net/http" "github.com/spiffe/go-spiffe/v2/spiffeid" "github.com/spiffe/go-spiffe/v2/spiffetls/tlsconfig" "github.com/spiffe/go-spiffe/v2/workloadapi" ) // PRODUCTION STANDARD: Ephemeral X.509 SVID attested via kernel UDS with auto-rotation func initSPIFFEClient(ctx context.Context, serverSPIFFEID string) (*http.Client, func(), error) { // Establish connection to local SPIRE Agent UDS (attests caller PID/cgroup/kernel metadata) source, err := workloadapi.NewX509Source(ctx) if err != nil { return nil, nil, err } expectedID, err := spiffeid.FromString(serverSPIFFEID) if err != nil { _ = source.Close() return nil, nil, err } // tlsconfig dynamically updates keys in-memory on rotation and strictly authorizes peer ID tlsConfig := tlsconfig.MTLSClientConfig(source, source, tlsconfig.AuthorizeID(expectedID)) client := &http.Client{ Transport: &http.Transport{TLSClientConfig: tlsConfig}, } cleanup := func() { _ = source.Close() } return client, cleanup, nil } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SPIFFE/SPIRE Ephemeral X.509 SVID Continuous Attestation and Rotation Standard

SPIFFE/SPIRE Ephemeral X.509 SVID Continuous Attestation and Rotation Standard defines an industrial-grade behavioral standard for security engineering. Enforces zero-trust workload authentication using SPIFFE/SPIRE Unix Domain Socket (UDS) kernel attestation without static secrets. Mandates in-memory dynamic SVID rotation watchers and explicit peer SPIFFE ID validation, prohibiting disk persistence and static secret fallbacks. 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: Static Secret Fallbacks and Disk-Persisted X.509 SVIDs Without Dynamic Rotation Watchers 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	Static Secret Fallbacks and Disk-Persisted X.509 SVIDs Without Dynamic Rotation Watchers	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:

Services MUST acquire cryptographic identities exclusively via the SPIRE Workload API over a local Unix Domain Socket (UDS) attested against OS/kernel metadata (cgroups, PID, UID).

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.