Learn: Compliance & regulated workloads — reference

A lookup reference, verified against code. No account IDs or emails appear here. Compliance on this platform is a lens over the security modules, not a subsystem of its own — so this is a short module with no deep dives. For the fuller picture, start with the orientation.

The model

Compliance-aware by design, not certified. There are two moving parts. A lens: the platform’s existing security controls are the compliance controls — compliance maps them, it doesn’t rebuild them. And a dial: a declared tier per environment, constrained by what the team’s envelope allows. The honest version — going regulated is a dial-turn, not a rebuild, but the dial sits at standard everywhere, the regulated settings are unproven in production, and the certify-and-prove machinery is mostly still designed. One live slice (PolicyReport→Grafana) is the exception.

Tier model (built as a data-model dimension)

• spec.tier on the XEnvironment claim is a hardening profile: one label bundling an isolation floor, an encryption floor, a network default, and a retention floor. It’s a floor — effective isolation = max(tier-floor, spec.isolation.compute). Default standard. A ComplianceTier tag propagates to resources via _base.hcl.
• Tiers (the policy module): standard (SOC 2 baseline), hipaa, pci — each with a prescriptive control table (compute/network isolation, encryption at rest + host, netpol default, WAF/IDS, log retention).
• Enum drift, worth flagging. The XRD (xenvironment-xrd.yaml ~L68-71) lists four — ["standard","elevated","pci","hipaa"] — adding elevated, which appears nowhere in the policy module and maps to no differentiated behavior. There’s also a stray invalid compliance_tier = "high" in the undeployed prod/…/workload.hcl (harmless only because prod isn’t real). Both are data-model inconsistencies an audit would flag.

Envelope validation — the constraint (Enforce on preprod)

A team can only request tiers, stages, and regions it’s licensed for. The Kyverno restrict-environment-envelope ClusterPolicy (infra/modules/crossplane/charts/environment-policies/templates/environment-envelope.yaml) reads the projected Team CR and denies out-of-envelope claims across four axes:

• tier-within-envelope — spec.tier ∈ Team.spec.envelope.allowedTiers.
• stage-within-envelope — spec.stage ∈ allowedStages.
• residency-within-envelope — spec.residency.allowedLocations ⊆ allowedLocations (residency is wired identically to tier).
• quota ≤ quotaCap; policystatements-no-escalation (deny-set IAM).

Live: enableEnvironmentEnvelope = true, envelopeFailureAction = "Enforce" on preprod. The module default is false/Audit, so the hub isn’t enforcing it yet.

What the tier actually toggles today (built but inert)

• The only tier-conditional behavior lives in pod-hardening.yaml (~L78): {{- if ne .Values.complianceTier "standard" }} gates two policies — require-pod-security-restricted (full Restricted PSS) and require-ro-rootfs (readOnlyRootFilesystem: true).
• It’s a per-cluster Helm-render gate, not per-namespace. complianceTier is a single module input from workload.hcl per cluster; the policies key on the environment-namespace selector (the platform.refplat.org/team label), not on a per-namespace tier label. So a regulated cluster hardens all its env workloads — which matches the whole-dedicated-cluster-as-regulated model.
• Both live clusters are standard, so ne "standard" is false and these two policies don’t render at all. They exist in code and unit tests only — not merely unexercised but absent from the running policy set.
• Everything else is tier-independent — image-registry scoping, rbac-hardening (restrict-binding-clusteradmin, restrict-wildcard-rbac), probes, requests/limits, automount-off, no-LoadBalancer, no-:latest, cosign verify. Every environment gets all of it, standard included. The regulated tiers only add the two policies on top.
• No regulated tenant exists. Every gitops/environments/** claim is tier: standard, and every team’s allowedTiers is ["standard"]. No team is even licensed for a regulated tier.

Compliance rides on the security modules (the controls are real and live)

The existing defense-in-depth controls are the compliance controls — the thesis is: map, don’t build.

Control	Where	Compliance role
Kyverno admission (Enforce)	Policy	preventive config controls
cosign + SLSA L3	Supply chain	software integrity / provenance
Pod Identity + deny-set IAM	Identity	least privilege / authorization
WireGuard + SPIRE mTLS	Runtime security	encryption in transit
NetworkPolicy default-deny	per-environment	network segmentation
8 org SCPs	organizations module	account-level preventive guardrails
CloudTrail (deployed both clusters)	aws/cloudtrail	audit trail
Falco (deployed both clusters)	Runtime security	runtime detection

tier and residency are the dial; these are the controls it’s meant to modulate. Today it modulates only the two (unrendered) PSS policies, and everything runs uniformly at standard.

Assurance & evidence (partly built)

• The gap: strong controls, no assurance — no bridge from “a control exists” to “continuous, tenant-attributable proof it’s enforced.”
• The three proposed pieces: (1) a control catalog as code mapped to SOC 2 / PCI / HIPAA IDs; (2) continuous scanning that aggregates signals which already exist (Kyverno PolicyReports, attestations, AWS Config/Security Hub) into a live control-status view (Grafana + Backstage); (3) evidence collection into retention-locked (S3 Object Lock) storage, per-tenant-attributable.
• Built, a real first slice: the observability-policy-reporter module is deployed on both clusters. It turns Kyverno PolicyReport/ClusterPolicyReport CRs into Prometheus metrics and Grafana dashboards, with live alerts (PolicyReportNewViolation, …) whose own comment calls policy fail/error results compliance evidence worth paging on. So piece (2)’s Kyverno→Grafana half is live. Alongside it, the hand-maintained static docs/compliance/scp-control-mapping.md (8 SCPs → SOC 2 / HIPAA / PCI / ISO 27001 / NIST 800-53 / CIS, with copy-paste auditor queries).
• Still unbuilt: the framework control catalog as code (1); the multi-source aggregation and the Backstage control-status view (rest of 2); retention-locked evidence collection (3).
• Also not built: K8s API-server audit-log shipping and its roll-up into evidence (distinct from the deployed CloudTrail).

Status ledger

• Live: the tier data-model dimension + ComplianceTier tag; envelope validation (tiers/stages/residency/quota — Enforce preprod); the underlying security controls (Kyverno, supply chain, Pod Identity, WireGuard, SCPs, CloudTrail, Falco).
• Built but inert: regulated-tier hardening (Restricted-PSS + RO-rootfs) — doesn’t render on either standard cluster; no per-namespace differentiation; no regulated tenant/team.
• Partly built: continuous scanning has a live slice — the Kyverno-PolicyReport→Grafana observability-policy-reporter (both clusters).
• Designed / aspirational: the framework control-catalog, multi-source aggregation + Backstage view, evidence collection; K8s API-audit shipping.

Gotchas

• “Which tier are we?” Both live clusters are standard, so the regulated policies aren’t running.
• Tier enum drift — the XRD has elevated (maps to nothing) that the module doesn’t. Prod has an invalid "high" (harmless, since prod is undeployed).
• Regulated means a whole cluster, not a namespace toggle (the per-cluster complianceTier render gate).
• “Show me the evidence” — Kyverno violations are live in Grafana (observability-policy-reporter), but the framework-mapped control catalog and retention-locked evidence store aren’t built, and the SCP→framework mapping is a hand-maintained doc.
• CloudTrail is deployed — what’s missing is K8s API-server audit plus evidence aggregation.

Go deeper

Rides on: Policy · Supply chain · Runtime security · Identity · Foundations. The static control map: docs/compliance/scp-control-mapping.md. External: HIPAA Security Rule · PCI DSS · Pod Security Standards.