SPIFFE/SPIRE TPM 2.0 Hardware-Rooted Workload Attestation Standard

--- description: SPIFFE/SPIRE TPM 2.0 Hardware-Rooted Workload Attestation Standard - Enforces cryptographic workload identity issuance bound to bare-metal TPM 2.0 secure enclaves via SPIFFE/SPIRE node and workload attestation. Eliminates static long-lived IAM tokens, secrets files, and ambient cloud credentials by requiring short-lived X.509 SVIDs rooted in measured boot Platform Configuration Registers (PCRs). globs: src/auth/**/*.{ts,js,go}, src/security/**/*.{ts,js,go}, deploy/spire/**/*.{yaml,conf,hcl}, infra/**/*.{tf,hcl} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/spiffe-spire-tpm2-hardware-workload-attestation-standard" --- # SPIFFE/SPIRE TPM 2.0 Hardware-Rooted Workload Attestation Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Bypassing Hardware Attestation with Static IAM Secret Keys or Unvalidated Local Workload Sockets ## System Constraints You are a Principal Security Architect and Rules Author enforcing strict zero-trust hardware attestation standards. Microservice identities must be rooted cryptographically in TPM 2.0 enclaves using SPIFFE/SPIRE. You must reject any static IAM keys, shared secrets, long-lived API tokens, or insecure IPC configurations that bypass the SPIFFE Workload API and measured boot verification. ## Strict Guidelines - Engineers MUST ALWAYS obtain service credentials dynamically through the SPIFFE Workload API over a protected Unix Domain Socket. - SPIRE Server configurations MUST validate bare-metal node identity against physical TPM 2.0 Endorsement Key (EK) certificates and Platform Configuration Registers (PCR 0-7, 10). - Engineers MUST NOT inject static AWS_ACCESS_KEY_ID, GCP service account keys, or long-lived static bearer tokens into container configurations or environment variables. - Workload SVIDs (X509-SVID) MUST have a maximum time-to-live (TTL) of 60 minutes and be automatically rotated in-memory without process interruption. - Workload registration entries MUST strictly enforce mutual cryptographic selectors (e.g., unix:uid, k8s:ns, k8s:sa) pinned exclusively to attested TPM-backed node SPIFFE IDs. - Components NEVER fall back to unauthenticated network transport or skip remote TLS peer certificate verification against the federated SPIFFE Trust Bundle. ## Bad vs Good Implementations ### Workload Identity Acquisition: Static Cloud IAM Credentials vs. SPIFFE Workload API #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Relies on persistent static IAM credentials stored in plain text environment variables. If the container or host memory is dumped, credentials can be exfiltrated without any hardware-level telemetry or cryptographic proof of platform integrity. ```typescript import { S3Client } from '@aws-sdk/client-s3'; // ANTI-PATTERN: Ambient static long-lived bearer tokens injected via environment export function createStorageClient(): S3Client { const accessKeyId = process.env.AWS_ACCESS_KEY_ID; const secretAccessKey = process.env.AWS_SECRET_ACCESS_KEY; if (!accessKeyId || !secretAccessKey) { throw new Error('Missing static cloud IAM credentials in environment variables'); } return new S3Client({ region: process.env.AWS_REGION || 'us-east-1', credentials: { accessKeyId, secretAccessKey } }); } ``` #### Production Standard (Correct) > **Standard**: Eliminates all static secrets. The workload proves its identity dynamically via the local SPIFFE agent socket. The agent's own node identity is backed by a physical TPM 2.0 secure cryptoprocessor, ensuring execution inside a cryptographically verified and attested runtime. ```typescript import { WorkloadApiClient } from '@spiffe/workload-api'; import { fromTokenFile } from '@aws-sdk/credential-providers'; import { S3Client } from '@aws-sdk/client-s3'; // PRODUCTION INVARIANT: Identity dynamically retrieved via local SPIFFE socket, verified by TPM 2.0 export async function createAttestedStorageClient(): Promise<S3Client> { const socketPath = process.env.SPIFFE_ENDPOINT_SOCKET ?? 'unix:///run/spire/sockets/agent.sock'; const spiffeClient = new WorkloadApiClient({ socketPath }); // Fetch hardware-rooted, short-lived X509-SVID & JWT-SVID for cloud role assumption const svidContext = await spiffeClient.fetchJwtSvid({ audience: ['https://sts.amazonaws.com'] }); const token = svidContext.svids[0]?.token; if (!token) { throw new Error('Hardware-rooted workload attestation failed: No SVID issued by SPIRE Agent'); } // Assume IAM Role dynamically using short-lived cryptographically signed TPM-attested JWT return new S3Client({ region: process.env.AWS_REGION || 'us-east-1', credentials: fromTokenFile({ webIdentityToken: token, roleArn: 'arn:aws:iam::123456789012:role/AttestedWorkloadExecutionRole', roleSessionName: 'spiffe-tpm-attested-session' }) }); } ```

Architectural Specification & Invariant Rationale

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

SPIFFE/SPIRE TPM 2.0 Hardware-Rooted Workload Attestation Standard defines an industrial-grade behavioral standard for security engineering. Enforces cryptographic workload identity issuance bound to bare-metal TPM 2.0 secure enclaves via SPIFFE/SPIRE node and workload attestation. Eliminates static long-lived IAM tokens, secrets files, and ambient cloud credentials by requiring short-lived X.509 SVIDs rooted in measured boot Platform Configuration Registers (PCRs). 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: Bypassing Hardware Attestation with Static IAM Secret Keys or Unvalidated Local Workload Sockets 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	Bypassing Hardware Attestation with Static IAM Secret Keys or Unvalidated Local Workload Sockets	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 obtain service credentials dynamically through the SPIFFE Workload API over a protected Unix Domain Socket.

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.