Zero-Trust Infrastructure Governance: Hardware-Backed mTLS, SPIFFE/SPIRE & Continuous SOC 2 / ISO 27001 Evidence

Traditional enterprise infrastructure security relies on two brittle illusions: first, that a private RFC 1918 VPC subnet bridged by an administrative VPN constitutes a trusted enclave; and second, that capturing manual configuration screenshots once a year demonstrates operational compliance with SOC 2 Type II or ISO/IEC 27001:2022. When an attacker compromises a single public-facing ingress parser or exfiltrates a static service key from a CI environment variable, flat east-west networks and long-lived bearer credentials convert a localized vulnerability into total institutional compromise.

For regulated sovereign clouds, financial clearing cores, and private AI clusters, security and compliance must operate as deterministic runtime invariants rather than manual checklists. This reference architecture details how our infrastructure practice replaces static secrets entirely with hardware-rooted SPIFFE/SPIRE cryptographic workload identities, enforces dual-layer micro-segmentation via Linux eBPF (Cilium) and Envoy L7 mTLS RBAC, gates deployments on SLSA Level 3 cryptographic provenance, and streams signed runtime telemetry directly into WORM object storage mapped to auditor-ready control matrices.

1. Replacing Static Secrets with Hardware-Attested SPIFFE/SPIRE

Every static credential stored in a Kubernetes Secret, mounted configuration file, or cloud secret manager introduces two operational liabilities: exfiltration blast radius and rotation fragility. Manual or cron-driven secret rotation routinely triggers production outages when half of a microservice fleet reloads an updated secret while peer replicas cache the invalidated token—burning entire quarterly availability budgets (model the impact of correlated control-plane incidents in our Composite SLA & Error Budget Calculator).

Hardware Root of Trust: TPM 2.0 Node Attestation & HSM CA Custody

SPIFFE (Secure Production Identity Framework for Everyone) assigns every workload a universal cryptographic URI—for example, spiffe://prod.rocketsoftware.ge/ns/core-fin/sa/ledger-poster—encoded inside the URI Subject Alternative Name (SAN) of a short-lived X.509 certificate called an X.509-SVID. However, an X.509-SVID is only as trustworthy as the physical hardware attesting the host node.

In our bare-metal and sovereign cloud deployments, the SPIRE trust hierarchy anchors directly into silicon:

• FIPS 140-3 Level 3 HSM Upstream Authority: The root Trust Domain private key resides permanently inside a dedicated network or PCIe Hardware Security Module accessed by the SPIRE Server cluster strictly over PKCS#11. Each regional SPIRE Server holds only a 24-hour intermediate CA certificate in locked kernel memory (mlock), ensuring root signing material can never be dumped from host RAM.
• TPM 2.0 Measured-Boot Node Attestation: Before a worker node joins the cluster or receives any workload SVIDs, its local SPIRE Agent proves hardware identity via the motherboard's discrete TPM 2.0 chip (tpm_devid plugin). The SPIRE Server validates the manufacturer-burned Endorsement Key (EK) certificate against our hardware inventory allowlist and verifies signed Platform Configuration Registers (PCRs 0, 2, 4, 7) proving UEFI Secure Boot, immutable bootloader integrity, and exact signed Linux kernel/initramfs SHA-256 measurements.

Kernel-Introspected Workload Attestation & Hourly Rotation

Application pods never possess a bootstrap secret or API key to authenticate to SPIRE. Instead, pods mount a read-only Unix Domain Socket exposing the SPIFFE Workload API. When a process connects, the node-local SPIRE Agent inspects kernel socket credentials (SO_PEERCRED) to extract the unforgeable caller PID, walks /proc/<pid>/cgroup to identify the exact container ID, queries the local container runtime and kubelet to verify the Pod UID, Namespace, ServiceAccount, and immutable OCI image SHA-256 digest, and matches those selectors against registered ClusterSPIFFEID policies.

Upon match, SPIRE mints a dedicated ECDSA P-256 X.509-SVID with a 60-minute TTL and streams it directly into process RAM (via native Go go-spiffe/v2 TLS hooks or Envoy's Secret Discovery Service). At the 30-minute mark (50% lifetime), SPIRE pushes a fresh certificate seamlessly over the open gRPC stream. Private keys never touch persistent NVMe block storage, and because leaf certificates expire naturally within 60 minutes, multi-region service meshes avoid synchronous OCSP/CRL revocation round-trips that would otherwise inflate cross-region tail latencies (estimate WAN RTT overhead here).

2. Kernel-Space eBPF Micro-Segmentation & Envoy L7 mTLS RBAC

Legacy network firewalls equate IPv4 addresses with identity. Inside high-density Kubernetes clusters—such as the multi-region topologies detailed in Designing Deterministic Active-Active Kubernetes Clusters Across Regions—Pod IPs recycle across unrelated namespaces within seconds during autoscaling events. Relying on CIDR-based iptables chains creates two severe hazards: linear O(N) netfilter rule traversal degrades packet forwarding latency above a few thousand services, and stale IP logs destroy forensic non-repudiation.

Defense-in-Depth: Socket/TC eBPF Plus Cryptographic L7 RBAC

True zero-trust micro-segmentation pairs fast kernel containment with cryptographic application-layer authorization:

1. L3/L4 Kernel Containment via Cilium eBPF: Cilium compiles declarative security policies into BPF bytecode attached directly to Linux Traffic Control (tc) and socket (sockops) hooks, bypassing legacy iptables completely. Every namespace defaults to total ingress and egress deny. Allowed flows match immutable cryptographic endpoint identities mapped in O(1) BPF hash tables with less than 12 microseconds of forwarding overhead, while node-to-node traffic traverses transparent kernel WireGuard encryption. Egress to external clearing APIs or object stores is locked to DNS-inspected FQDNs and specific TCP ports, blocking reverse-shell C2 callbacks even if a parser process suffers memory corruption.
2. L7 Mutual TLS & Method-Scoped RBAC via Envoy: Kernel packet filters verify where packets originate, whereas Envoy verifies who signed the TLS 1.3 handshake and which exact RPC verb is invoked. Consuming SPIRE X.509-SVIDs and federated trust bundles over SDS, Envoy validates the peer certificate chain and enforces exact URI SAN matching inside envoy.filters.http.rbac. For instance, in our Sub-Millisecond Double-Entry Financial Ledger deployment, only spiffe://prod.rocketsoftware.ge/ns/payments-gw/sa/ingress-router is authorized to invoke POST /ledger.v1.PostingService/PostJournal, whereas sa/reconciliation-daemon is cryptographically restricted to read-only /ledger.v1.AuditService/VerifyHashChain calls. Similarly, inside Sovereign On-Premise LLM & Air-Gapped RAG Clusters, vector database shards reject any retrieval query lacking a mutually authenticated orchestrator SVID.

3. Immutable Infrastructure & SLSA Level 3 Supply-Chain Provenance

Runtime workload identity is only half of the integrity equation: if an adversary compromises a developer laptop or injects an unauthorized image tag into an OCI registry under an existing Kubernetes Deployment's name, SPIRE would dutifully issue a valid SVID unless image provenance is cryptographically pinned and verified at admission.

Non-Falsifiable SLSA v1.0 Build Level 3 Pipelines

To satisfy SOC 2 Change Management (CC8.1) and ISO/IEC 27001:2022 Secure Development & Change Control (A.8.25, A.8.32) mathematically, every production artifact passes through a hermetically isolated build pipeline:

• Ephemeral Single-Tenant Runners: Every CI build boots a fresh, single-use Firecracker microVM from a read-only golden snapshot with no persistent volumes and no shared memory across concurrent jobs, destroying the VM immediately after artifact upload.
• Signed Provenance & SBOM Attestations: An isolated control-plane signing service—inaccessible to user-defined build scripts—generates an in-toto SLSA v1.0 Build Level 3 provenance statement recording the exact Git commit SHA, two-party peer-reviewed PR approval metadata, build workflow digest, and complete CycloneDX Software Bill of Materials (SBOM). Both the container digest and its attestations are signed via Sigstore Cosign using an HSM-backed KMS key and recorded in a private Rekor transparency log.
• Immutable Host OS & Zero-SSH Posture: Worker nodes boot minimal, API-managed immutable Linux images (read-only squashfs / dm-verity verified /usr partitions) with sshd and interactive shells completely removed. Host configuration drift is structurally impossible; every OS patch rolls out as an atomic, TPM-measured node replacement.

4. Production Policy Manifests: SPIRE, Cilium & Kyverno

Below are the three foundational declarative manifests that bind cryptographic identity, kernel micro-segmentation, and supply-chain admission enforcement together in our production Kubernetes clusters.

1. SPIRE Controller Manager — ClusterSPIFFEID Registration

This custom resource instructs SPIRE to mint 1-hour X.509-SVIDs exclusively for pods running inside the core-fin namespace under the ledger-poster ServiceAccount on TPM-attested bare-metal worker nodes:

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: core-fin-ledger-poster
spec:
  spiffeIDTemplate: "spiffe://{{ .TrustDomain }}/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}"
  ttl: 1h
  autoPopulateDNSNames: false
  federatesWith:
    - "eu-frankfurt.rocketsoftware.ge"
    - "me-dubai.rocketsoftware.ge"
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: core-fin
      security.rsg.io/tier: regulated-pci-soc2
  podSelector:
    matchLabels:
      app.kubernetes.io/name: ledger-poster
  workloadSelectorTemplates:
    - "k8s:sa:ledger-poster"
    - "k8s:container-name:poster"

2. Cilium eBPF Default-Deny & Identity-Scoped Micro-Segmentation

This CiliumNetworkPolicy enforces default-deny ingress and egress on the ledger posting tier, permitting inbound TLS 1.3 connections strictly from the API gateway identity on port 8443 and outbound connections solely to the synchronous PostgreSQL 17 primary cluster on port 5432:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: ledger-poster-zero-trust-isolation
  namespace: core-fin
spec:
  description: "Strict eBPF L3/L4 isolation for double-entry ledger posting pods"
  endpointSelector:
    matchLabels:
      app.kubernetes.io/name: ledger-poster
  ingress:
    - fromEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: payments-gw
            app.kubernetes.io/name: ingress-router
      toPorts:
        - ports:
            - port: "8443"
              protocol: TCP
  egress:
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: stateful-db
            app.kubernetes.io/name: pg17-ledger-cluster
            spilo-role: master
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
          rules:
            dns:
              - matchPattern: "*.stateful-db.svc.cluster.local"

3. Kyverno Validating Admission Gate — Cosign & SLSA Level 3 Verification

Before the Kubernetes scheduler places any pod onto a node, Kyverno intercepts the AdmissionReview webhook, rejects mutable tags unless pinned or mutated to immutable SHA-256 digests, validates the HSM-backed Cosign image signature against our private Rekor transparency log, and asserts that the signed SLSA v1.0 provenance predicate originated from our hardened build control plane and protected refs/heads/main branch:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-slsa-l3-cryptographic-provenance
spec:
  validationFailureAction: Enforce
  background: true
  webhookTimeoutSeconds: 10
  failurePolicy: Fail
  rules:
    - name: verify-cosign-signature-and-slsa-provenance
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["core-fin", "payments-gw", "stateful-db", "sovereign-ai"]
      verifyImages:
        - imageReferences:
            - "registry.internal.rsg/*"
          mutateDigest: true
          verifyDigest: true
          required: true
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7xR9wV3kP8zL2mN6qJ1cT4vB9yH0
                      dF5sK2wG8nL3pQ6rM1xV4cZ7bN0mK9jH2gF5dS8aP1oI4uY7tR0eW3qA6zX9cV2b==
                      -----END PUBLIC KEY-----
                    rekor:
                      url: https://rekor.sec.internal.rsg
                      ignoreTlog: false
          attestations:
            - type: https://slsa.dev/provenance/v1
              attestors:
                - count: 1
                  entries:
                    - keys:
                        publicKeys: |-
                          -----BEGIN PUBLIC KEY-----
                          MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7xR9wV3kP8zL2mN6qJ1cT4vB9yH0
                          dF5sK2wG8nL3pQ6rM1xV4cZ7bN0mK9jH2gF5dS8aP1oI4uY7tR0eW3qA6zX9cV2b==
                          -----END PUBLIC KEY-----
              conditions:
                - all:
                    - key: "{{ buildDefinition.buildType }}"
                      operator: Equals
                      value: "https://rocketsoftware.ge/slsa/ephemeral-firecracker-builder@v1"
                    - key: "{{ runDetails.builder.id }}"
                      operator: Equals
                      value: "https://ci-signer.sec.internal.rsg/builders/prod-l3"

5. Continuous Compliance Pipelines & SOC 2 / ISO 27001 Mapping

The highest-leverage outcome of zero-trust engineering is eliminating manual audit evidence gathering. Instead of assigning senior systems engineers to spend four weeks every quarter exporting CSV user lists and screenshotting firewall consoles, we operate an automated Evidence-as-Code telemetry pipeline that collects, cryptographically seals, and evaluates compliance posture continuously.

OpenTelemetry Collector to S3 Object Lock (COMPLIANCE WORM)

Every bare-metal node and control-plane component streams five structured security event channels into a hardened DaemonSet and Gateway tier of OpenTelemetry Collectors over mutually authenticated SPIFFE TLS:

1. Linux Kernel auditd & eBPF Tetragon Events: Process execution lineage (execve), privilege capability checks, kernel module load blocks, and unexpected socket syscalls tagged with container SPIFFE IDs.
2. SPIRE Issuance & Attestation Logs: Every TPM quote verification, node registration, and 30-minute X.509-SVID rotation receipt.
3. Envoy L7 RBAC & Cilium Flow Logs (Hubble): Sampled allowed flows and 100% of DENY / HTTP 403 Forbidden events with full caller/callee SPIFFE URI attribution.
4. Kubernetes Audit Webhook & Kyverno Admission Receipts: Every API mutation paired with the verified Cosign/SLSA Level 3 image digest admitted into production.
5. OPA Posture Assertions: Every 15 minutes, a scheduled Open Policy Agent evaluator snapshots live cluster state and emits signed pass/fail control assertions (for example, asserting zero pods lack CiliumNetworkPolicy coverage and zero certificates carry TTLs exceeding 3600s).

The OpenTelemetry Gateway aggregates these streams into hourly Zstandard-compressed Parquet and JSONL bundles, computes a chained SHA-256 manifest signed by an HSM audit key, and writes the bundle to a dedicated sovereign MinIO / S3 cluster configured with S3 Object Lock in COMPLIANCE mode (7-year retention). Under COMPLIANCE mode, storage firmware enforces Write-Once-Read-Many (WORM) semantics: not even the root storage administrator can overwrite, truncate, or shorten the retention window of an evidence bundle.

When external auditors begin a SOC 2 Type II examination period or ISO/IEC 27001 surveillance audit, we grant their verification tooling read-only IAM access to the WORM bucket and a standalone CLI verifier that validates the HSM signatures, SHA-256 chains, and 15-minute OPA control evaluations across the entire 365-day observation window in minutes.

6. Cryptographic Break-Glass Governance & Rotation Resilience

Zero-trust architectures fail in production if engineers overlook two operational realities: emergency incident response when orchestration APIs degrade, and control-plane survival during SPIRE maintenance. Both must be engineered explicitly without weakening security invariants:

• Quorum-Signed Hardware Break-Glass: Because production nodes run immutable filesystems without SSH daemons, emergency kernel-level debugging uses an out-of-band, time-bounded capability protocol. Initiating a break-glass diagnostic pod or serial console session requires a 2-of-4 FIDO2 / YubiKey PIV hardware signature quorum from designated principal engineers. The quorum service mints a single-use, 30-minute client certificate, triggers an immediate P1 alert in PagerDuty and the SIEM, and streams every multiplexer frame synchronously into the WORM compliance vault under SOC 2 CC6.2 privileged-access review tags.
• Overlapping SVID Grace Windows & Federated Trust Bundles: Workloads request SVID renewal at 50% of their 1-hour TTL (30 minutes remaining) with exponential jitter. If the regional SPIRE Server cluster undergoes rolling upgrades or database maintenance for 15 minutes, every running pod continues serving zero-error mTLS traffic on its existing in-memory certificate while SPIRE Agents retry asynchronously. Across active-active regions, federated trust bundles carry a 48-hour CA rotation overlap, ensuring WAN partitions never trigger spurious TLS handshake rejections.

Related Engineering Resources

Explore companion reference architectures and browser-local sizing calculators built by our principal engineering practice: