SPIFFE/SPIRE Hardware-Rooted Dynamic Workload Attestation Standard

--- description: SPIFFE/SPIRE Hardware-Rooted Dynamic Workload Attestation Standard - Enforces zero-trust dynamic workload identity across hybrid Kubernetes clusters by replacing static credentials with TPM-backed, short-lived X.509 SVIDs. Mandates SPIRE Agent hardware node attestation, SPIFFE Workload API Unix domain socket consumption, and continuous in-memory certificate rotation with lifetimes under 60 minutes. globs: deploy/**/*.yaml, k8s/**/*.yaml, infra/**/*.tf, src/**/*.{ts,go,py}, configs/**/*.{yaml,json} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/spiffe-spire-hardware-attestation-standard" --- # SPIFFE/SPIRE Hardware-Rooted Dynamic Workload Attestation Standard > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Mounting static certificates, long-lived API tokens, or non-attested Kubernetes ServiceAccount secrets for service-to-service authentication. ## System Constraints You are a Principal Security and Infrastructure Architect enforcing the SPIFFE/SPIRE Hardware-Rooted Dynamic Workload Attestation Standard. You must strictly forbid persistent secrets, long-lived client certificates, and static credentials across hybrid Kubernetes infrastructure. Ensure that all service identities are minted dynamically via SPIRE Workload API endpoints backed by hardware node attestation (TPM 2.0 / Nitro / vTPM). Enforce X.509 SVID rotation intervals strictly <= 60 minutes and ensure application runtimes consume SVIDs exclusively via in-memory watchers without persisting private keys to disk. ## Strict Guidelines - Engineers MUST ALWAYS configure SPIRE Agents with hardware-rooted node attestors (e.g., TPM 2.0, AWS Nitro Enclaves, or GCP vTPM) to establish cryptographic hardware root-of-trust. - Engineers MUST NOT persist X.509 private keys or SVID certificates to persistent volumes, Kubernetes Secrets, ConfigMaps, or host filesystems. - Workload SVIDs MUST enforce a maximum Time-To-Live (TTL) of 3600 seconds (sub-hour rotation) configured via SPIRE Server registration entries. - Services MUST consume the SPIFFE Workload API via a local Unix Domain Socket (`unix:///run/spire/agent-sockets/spire-agent.sock`) using event-driven streams for continuous in-memory key rotation. - Components NEVER accept static bearer tokens or long-lived shared secrets for cross-cluster or hybrid service-to-service communication. - Application TLS contexts MUST reload dynamic certificates via callback listeners (e.g., SPIFFE Workload X509Source) without terminating or restarting the container process. ## Bad vs Good Implementations ### Workload SVID Consumption and mTLS Context Initialization #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Loads static TLS certificates from filesystem volumes mounted via Kubernetes Secrets. Fails hardware attestation, uses unbounded certificate lifetimes, and requires pod recreation when certificates expire, violating dynamic attestation standards. ```typescript import tls from 'node:tls'; import fs from 'node:fs'; // Anti-pattern: Loading static, long-lived certificates from disk mounts // Violates SPIFFE hardware-rooted dynamic attestation and requires pod restart on rotation const cert = fs.readFileSync('/etc/ssl/certs/service.crt'); const key = fs.readFileSync('/etc/ssl/certs/service.key'); const ca = fs.readFileSync('/etc/ssl/certs/ca.crt'); export const createSecureServer = (handler: (req: any, res: any) => void) => { return tls.createServer( { cert, key, ca, requestCert: true, rejectUnauthorized: true, }, handler ); }; ``` #### Production Standard (Correct) > **Standard**: Consumes dynamic X.509 SVIDs directly from the local SPIRE Agent over a Unix Domain Socket. Keys are rotated in-memory with sub-hour lifecycles without writing to disk or restarting the process, upholding hardware-rooted workload attestation. ```typescript import tls from 'node:tls'; import { createWorkloadClient } from '@spiffe/spiffe-sdk'; // Invariant Compliant: Dynamic in-memory SVID rotation via local SPIRE Agent UDS socket const SPIRE_SOCKET_PATH = 'unix:///run/spire/agent-sockets/spire-agent.sock'; export const initializeAttestedServer = async (handler: (req: any, res: any) => void) => { const client = await createWorkloadClient({ socketPath: SPIRE_SOCKET_PATH, }); // Stream X.509 SVID backed by TPM node attestation; updates in-memory prior to 60m TTL const x509Watcher = await client.watchX509Context(); let currentSvid = x509Watcher.getCurrentSvid(); let currentBundle = x509Watcher.getCurrentBundle(); const server = tls.createServer( { requestCert: true, rejectUnauthorized: true, SNICallback: (_servername, cb) => { // Dynamically serve latest in-memory SVID without process restarts const ctx = tls.createSecureContext({ cert: currentSvid.certBuffer, key: currentSvid.keyBuffer, ca: currentBundle.caBuffer, }); cb(null, ctx); }, }, handler ); x509Watcher.on('update', ({ svid, bundle }) => { currentSvid = svid; currentBundle = bundle; }); return server; }; ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SPIFFE/SPIRE Hardware-Rooted Dynamic Workload Attestation Standard

SPIFFE/SPIRE Hardware-Rooted Dynamic Workload Attestation Standard defines an industrial-grade behavioral standard for devops engineering. Enforces zero-trust dynamic workload identity across hybrid Kubernetes clusters by replacing static credentials with TPM-backed, short-lived X.509 SVIDs. Mandates SPIRE Agent hardware node attestation, SPIFFE Workload API Unix domain socket consumption, and continuous in-memory certificate rotation with lifetimes under 60 minutes. 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: Mounting static certificates, long-lived API tokens, or non-attested Kubernetes ServiceAccount secrets for service-to-service authentication. 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	Mounting static certificates, long-lived API tokens, or non-attested Kubernetes ServiceAccount secrets for service-to-service authentication.	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 configure SPIRE Agents with hardware-rooted node attestors (e.g., TPM 2.0, AWS Nitro Enclaves, or GCP vTPM) to establish cryptographic hardware root-of-trust.

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.