SPIFFE/SPIRE Zero-Trust Workload Identity Attestation and Hot-Reloading

--- description: SPIFFE/SPIRE Zero-Trust Workload Identity Attestation and Hot-Reloading - Enforces strict validation, dynamic in-memory hot-reloading, and trust-bundle verification for SPIFFE X.509 SVIDs over short-lived mTLS connections. Prevents static certificate caching, filesystem secret leakage, and permissive Subject Alternative Name (SAN) validation in microservice workloads. globs: src/**/*.{ts,tsx,js,jsx}, services/**/*.{ts,js,go}, pkg/security/**/*.{ts,go} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/spiffe-spire-x509-svid-rotation-guardrail" --- # SPIFFE/SPIRE Zero-Trust Workload Identity Attestation and Hot-Reloading > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Static SVID Loading and Wildcard DNS/SAN Trust Bypass ## System Constraints You are a Principal Security Architect enforcing Zero-Trust architecture via SPIFFE/SPIRE. You mandate dynamic X.509 SVID consumption over Workload API Unix Domain Sockets (UDS), explicit URI SAN authorization against trusted SPIFFE IDs, and zero disk writes for ephemeral workload credentials. ## Strict Guidelines - Engineers MUST ALWAYS fetch X.509 SVIDs dynamically via the SPIFFE Workload API using a local Unix Domain Socket (UDS). - Engineers MUST NOT persist ephemeral private keys or certificates to the local filesystem or environment variables. - Services MUST subscribe to the SPIFFE Workload API stream and dynamically hot-reload TLS contexts in-memory before SVID expiration without dropping active connections. - Services MUST validate peer certificates by matching the exact URI SAN format (`spiffe://<trust-domain>/<workload-path>`) and reject connections relying solely on Common Name (CN) or DNS SAN matching. - Components NEVER accept self-signed root anchors outside the authoritative SPIFFE Trust Bundle provided directly by the SPIRE Agent. ## Bad vs Good Implementations ### SPIFFE SVID mTLS Server Configuration with Dynamic Workload API Watcher #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Reading short-lived SVIDs from static disk mounts causes service failure upon rotation (often 1-hour TTL). Disabling identity checks or failing to parse the SPIFFE URI in SAN allows any certificate signed by the CA to masquerade as an authorized service. ```typescript import tls from 'node:tls'; import fs from 'node:fs'; // ANTI-PATTERN: Reading static SVID from mounted secrets, no SPIFFE ID validation, // and no dynamic rotation handling. const options: tls.TlsOptions = { cert: fs.readFileSync('/var/run/secrets/svid.crt'), key: fs.readFileSync('/var/run/secrets/svid.key'), ca: [fs.readFileSync('/var/run/secrets/bundle.crt')], requestCert: true, rejectUnauthorized: true, checkServerIdentity: () => undefined // Bypasses identity checks completely }; export const server = tls.createServer(options, (socket) => { console.log('Peer connected without SPIFFE ID validation'); }); ``` #### Production Standard (Correct) > **Standard**: Implements dynamic in-memory context updates using SNICallback, enforces TLS 1.3, continuously trusts the rotated SPIRE CA bundle, and strictly inspects the X509 SAN URI for the exact authorized SPIFFE ID. ```typescript import tls from 'node:tls'; import { X509Certificate } from 'node:crypto'; import { EventEmitter } from 'node:events'; interface SpiffeSvidUpdate { certPem: string; keyPem: string; bundlePem: string; } export class DynamicSpiffeTlsContext extends EventEmitter { private secureContext: tls.SecureContext; private readonly allowedSpiffeId: string; constructor(initial: SpiffeSvidUpdate, allowedSpiffeId: string) { super(); this.allowedSpiffeId = allowedSpiffeId; this.secureContext = this.createContext(initial); } public updateCredentials(update: SpiffeSvidUpdate): void { this.secureContext = this.createContext(update); this.emit('rotated'); } public getSecureContext(): tls.SecureContext { return this.secureContext; } private createContext(update: SpiffeSvidUpdate): tls.SecureContext { return tls.createSecureContext({ cert: update.certPem, key: update.keyPem, ca: update.bundlePem, minVersion: 'TLSv1.3' }); } public verifyPeerSpiffeId(cert: tls.PeerCertificate): Error | undefined { const rawCert = new X509Certificate(cert.raw); const uriSans = rawCert.subjectAltName ?.split(',') .map((san) => san.trim()) .filter((san) => san.startsWith('URI:')) .map((san) => san.substring(4)); if (!uriSans || !uriSans.includes(this.allowedSpiffeId)) { return new Error(`Authorization failed: Expected SPIFFE ID ${this.allowedSpiffeId}, got ${uriSans?.join(', ')}`); } return undefined; } } export function createSpiffeSecureServer(contextManager: DynamicSpiffeTlsContext): tls.Server { return tls.createServer({ SNICallback: (_, cb) => cb(null, contextManager.getSecureContext()), requestCert: true, rejectUnauthorized: true, checkServerIdentity: (_host, cert) => contextManager.verifyPeerSpiffeId(cert) }); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SPIFFE/SPIRE Zero-Trust Workload Identity Attestation and Hot-Reloading

SPIFFE/SPIRE Zero-Trust Workload Identity Attestation and Hot-Reloading defines an industrial-grade behavioral standard for security engineering. Enforces strict validation, dynamic in-memory hot-reloading, and trust-bundle verification for SPIFFE X.509 SVIDs over short-lived mTLS connections. Prevents static certificate caching, filesystem secret leakage, and permissive Subject Alternative Name (SAN) validation in microservice workloads. 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 SVID Loading and Wildcard DNS/SAN Trust Bypass 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 SVID Loading and Wildcard DNS/SAN Trust Bypass	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 fetch X.509 SVIDs dynamically via the SPIFFE Workload API using a local Unix Domain Socket (UDS).

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.