K8s & OpenShift: Compliance

Part 6 covered the operational loop: GitOps, observability, cost control, and upgrades. This final part maps the cluster configuration covered throughout this series to the regulatory frameworks that require it — NIS2, DORA, PCI-DSS, HIPAA, and the Cyber Resilience Act (CRA) — and covers the two topics that compliance work adds on top of security: audit logging as evidence and log retention as a contractual obligation.

Series navigation:

• Full guide: The Kubernetes & OpenShift Best Practices Guide (2026 Edition)
• Part 1 — The Big Picture
• Part 2 — Building workloads right
• Part 3 — Resource management deep dive
• Part 4 — Scaling & resilience
• Part 5 — Security
• Part 6 — Day-2 operations & GitOps
• Part 7 — Compliance (this post)

Compliance is already in the YAML🔗

The most useful framing for compliance in Kubernetes is not “what extra controls do we need” — it is “which controls are already in place, and can we prove it?” The practices from Parts 2 through 6 — RBAC, PSA, NetworkPolicy, image signing, audit logging, GitOps — are the technical implementation of the controls that regulators and auditors require. What compliance work adds is:

1. A mapping from those controls to the specific regulatory language
2. Audit logging that produces evidence that the controls are active
3. Log retention that keeps the evidence available for the required period
4. Incident reporting procedures that use the observability data from Part 6

This part covers five frameworks — the ones most commonly encountered when running Kubernetes in regulated environments.

The five frameworks🔗

These frameworks overlap significantly in their technical requirements. The controls they describe — access control, encryption, audit trails, network segmentation, incident response — are the same regardless of which framework applies. The differences are primarily in scope, reporting timelines, and retention periods.

CRA is the odd one out in one respect: NIS2, DORA, PCI-DSS, and HIPAA all regulate the entity operating a system, while CRA obligations fall on the manufacturer placing a product on the market. A team running Kubernetes purely to operate its own internal systems is not itself a CRA manufacturer — but the moment that cluster runs software the organisation ships to others (a SaaS product, an open-source project, an embedded component), CRA’s vulnerability-handling and SBOM obligations apply to that software, and Part 5’s image scanning and signing controls are the technical starting point for meeting them.

Controls mapping🔗

The table below maps the Kubernetes controls covered in this series to their regulatory anchors. “Part” references point to where the control is implemented and explained.

Kubernetes API audit logging🔗

The Kubernetes API server can log every request made against it: who called what, on which resource, from where, with what outcome. This is the primary source of the audit trail that compliance frameworks require — evidence that access controls are working, that changes are traceable, and that security events can be reconstructed.

Audit logging is controlled by an audit policy file provided to the API server, described in full in the Kubernetes auditing documentation. The policy defines which requests are logged and at what level of detail:

A production-grade audit policy captures access to sensitive resources at high fidelity while suppressing high-volume low-value reads that would fill the log with noise:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  # Suppress routine read-only requests to non-sensitive resources
  - level: None
    verbs: ["get", "watch", "list"]
    resources:
      - group: ""
        resources: ["events", "endpoints", "configmaps"]
      - group: "coordination.k8s.io"
        resources: ["leases"]

  # Full detail for Secret access — the primary sensitive resource
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]

  # Capture all writes at Request level — who changed what and to what
  - level: Request
    verbs: ["create", "update", "patch", "delete", "deletecollection"]

  # Capture all authentication events at Request level
  - level: Request
    users: ["system:anonymous"]
    verbs: ["*"]

  # Catch-all: metadata only for everything else
  - level: Metadata

Pass this file to the API server via --audit-policy-file and configure an output sink:

• --audit-log-path — write to a file on the control plane node (then ship with Fluent Bit)
• --audit-webhook-config-file — stream directly to a remote backend (Elasticsearch, Loki, etc.)

On managed clusters, audit logging is configured through the provider’s control plane settings, not directly:

• EKS — control plane logs are shipped to CloudWatch Logs
• AKS — audit logs are sent to a Log Analytics workspace
• GKE — audit logs are routed to Cloud Logging
• OVH MKS — produces real, object-level kube-apiserver audit events under a fixed, non-configurable policy (Secret and ConfigMap changes at Metadata level in all namespaces, create/patch/update/delete verbs at RequestResponse level, everything else at Request or Metadata level)
• STACKIT SKE — currently only audits the SKE management API itself (cluster creation, node pool changes, credential rotation), not kube-apiserver object-level events; per the official SKE FAQ, integrating true Kubernetes API audit logs into the STACKIT Telemetry Router is “still in active development and not generally available yet.” The delivery mechanism for the existing management-API audit log did move forward: STACKIT’s Telemetry Router went GA on 2 June 2026, replacing the old Audit Log API, and can route audit data directly to an external OTLP or S3-compatible destination — not only STACKIT’s own services.

Check the provider’s documentation for enabling and configuring the audit log. For frameworks that require proof of who accessed or modified a specific Kubernetes object (NIS2, DORA, PCI-DSS Req 10), the SKE gap above is not closed by the platform today — an in-cluster audit webhook or sidecar approach would need to substitute until the managed integration ships.

Both platforms’ audit-log tooling are moving targets. Everything in this section reflects what was verifiable on 1 July 2026 — re-check the provider’s current documentation before relying on it for a compliance sign-off.

Where these audit logs end up, and what that costs🔗

Producing the audit events is only half the picture. On both platforms, actually storing and querying them requires a separate, dedicated logging service — audit log retention is not bundled into the base Kubernetes service price.

OVH MKS forwards audit events by subscription (POST /cloud/project/{serviceName}/kube/{kubeId}/log/subscription) to a stream in OVH’s own Logs Data Platform (LDP), a Graylog/OpenSearch-based service in the same OVHcloud account. There is no option to forward audit events directly to an external sink — routing them into a separately-run pipeline (for example the ClickHouse-based stack from the log backend comparison series) means reading them back out through LDP’s OpenSearch or Graylog API and re-shipping them yourself. This is not a documentation gap: a direct S3-bucket export option for SIEM integration is an open, unaddressed request on OVH’s public roadmap as of December 2025.

STACKIT routes its existing (management-API) audit log through the Telemetry Router, GA since 2 June 2026. Unlike OVH’s LDP-only path, the Telemetry Router can send data straight to an external OTLP-compatible endpoint or S3-compatible storage — including a SIEM or bucket you operate yourself — instead of only STACKIT’s own services. That routing itself is billed separately from wherever the data ends up: the Telemetry Router charges for ingestion regardless of destination. If you route it to STACKIT Logs (Loki-based) as the destination, that service adds its own ingestion and storage cost on top, and enforces a hard 180-day retention cap that is not configurable per stream; STACKIT’s own FAQ describes a dual-write pattern for retention beyond that cap: stream logs to STACKIT Logs and, in parallel, to a separate object storage bucket. Whether the still-pending kube-apiserver object-level integration will ship through this same Telemetry Router, and inherit its external-destination flexibility, is not confirmed yet.

Prices and feature availability as observed on 1 July 2026 — both platforms’ audit-log products are under active development and can change on short notice; check current documentation before relying on these figures.

Every use case should document in writing how important its Kubernetes audit logs are and which of the Log retention requirements apply — that is what determines how much effort, and which of the solutions above, the audit log setup actually warrants. Given the per-GB pricing above, retention requirements can turn into a real cost factor once volume and duration add up, not just an engineering effort decision.

oc patch apiserver cluster --type=merge \
  -p '{"spec":{"audit":{"profile":"WriteRequestBodies"}}}'

What the audit log contains🔗

Each audit event is a JSON object. The fields that matter most for compliance purposes:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Request",
  "auditID": "e9f7a421-...",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/myapp/secrets/db-password",
  "verb": "get",
  "user": {
    "username": "ci-pipeline",
    "groups": ["system:authenticated"]
  },
  "sourceIPs": ["10.0.1.42"],
  "responseStatus": {"code": 200},
  "requestReceivedTimestamp": "2026-07-04T14:32:01.123456Z"
}

The combination of username, verb, requestURI, sourceIPs, and requestReceivedTimestamp answers the auditor’s question: who accessed what, from where, and when.

Log retention requirements🔗

Retaining audit logs for the required period is a separate concern from generating them. The retention obligation varies by framework:

CRA is deliberately absent from this table: it does not prescribe a fixed log retention period at all, leaving the duration to a risk-based judgment tied to vulnerability handling and incident reporting timelines. What CRA does mandate with a fixed duration is different in kind — technical documentation and the SBOM must be kept for 10 years after the product is placed on the market, or for the support period, whichever is longer. That is a compliance-documentation retention obligation, not a security-log retention rule, and it should not be conflated with the frameworks above.

PCI-DSS v4.0 Requirement 10.5.1 deserves attention: the 3-month immediate accessibility requirement means that audit logs from the past 3 months must be queryable — not just archived to cold storage. A Loki, Elasticsearch, or ClickHouse cluster with a 90-day hot tier satisfies this; a setup where all logs older than 30 days go to Glacier or equivalent does not.

For the technical implementation of log storage backends and their cost/retention trade-offs — Elasticsearch/OpenSearch, Loki, Quickwit, ClickHouse — the managed log archiving series covers each option in depth, including provider-specific configurations for each managed Kubernetes platform. The log backend comparison covers query performance, ingestion rates, and storage costs across the five backends.

That choice of backend is not fully free on OVH MKS and STACKIT SKE if you rely on the platform’s own audit-log service described above. OVH’s Logs Data Platform can hold data for the required duration via its archived storage tier (up to 10 years), but archived logs are not queryable — only downloadable as compressed files — so anything past the 1-year indexed retention window loses the same live-accessibility property that Requirement 10.5.1 demands for PCI-DSS. On STACKIT, it depends on where the Telemetry Router points: STACKIT Logs on its own enforces a hard 180-day retention cap that cannot be extended, structurally short of DORA’s 5-year and HIPAA’s 6-year requirements — but since the Telemetry Router emits to multiple destinations in parallel, routing a second copy straight to your own long-term object storage alongside STACKIT Logs is a native configuration rather than a workaround. Either way, none of this closes the coverage gap from the section above — as of this writing, it only applies to the SKE management-API audit log, not the still-pending kube-apiserver object-level events. Check which retention tier a framework actually needs — queryable or merely retained — against what the platform’s native service provides before assuming it is covered.

Incident reporting timelines🔗

Regulatory incident reporting requires knowing what happened, when, and what was affected — which is the same information that the observability stack from Part 6 provides. The audit log and the application logs are the primary evidence for incident reports.

The NIS2 24-hour early warning and DORA 4-hour notification are not expected to contain a full root-cause analysis — they are notifications that an incident occurred and is being managed. The final report, due one month later, is where the full timeline, affected systems, impact assessment, and remediation actions are documented.

What the Kubernetes environment contributes to incident reports:

• API audit log — proves who had access, what they did, and when; rules out (or confirms) insider access or credential misuse
• Application logs — reconstructs the sequence of events from the application’s perspective
• Metrics and alerts — shows when anomalous behaviour started, which workloads were affected, and what the blast radius was
• GitOps history — proves what the desired state was at any point in time and whether unauthorised changes occurred

A cluster without centralised logging and a GitOps audit trail makes incident reporting significantly harder — the timeline has to be reconstructed from fragments rather than read from a structured record.

Compliance scanning🔗

Automated compliance scanning tests the cluster’s current configuration against known benchmark profiles. Two tools are widely used:

kube-bench🔗

kube-bench runs the CIS Kubernetes Benchmark checks against the API server, controller manager, scheduler, and nodes. It is the starting point for assessing how much of the CIS benchmark the cluster already satisfies.

# Run as a Job on the cluster
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

The output lists each check with a PASS/FAIL/WARN status and the remediation for failures. CIS Kubernetes Benchmark is not a regulatory requirement itself, but it maps to the technical controls required by NIS2, DORA, PCI-DSS, and HIPAA — passing the benchmark provides a documented baseline.

OpenShift Compliance Operator🔗

The OpenShift Compliance Operator runs OpenSCAP-based scans against cluster nodes and platform components. It ships profiles for:

• CIS Kubernetes Benchmark
• NIST SP 800-53 (moderate and high impact)
• PCI-DSS
• HIPAA

A ScanSetting and ScanSettingBinding trigger periodic scans:

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: pci-dss-scan
  namespace: openshift-compliance
profiles:
  - name: ocp4-pci-dss
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: default
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1

Scan results appear as ComplianceCheckResult objects. Failed checks surface in the OpenShift console under the Compliance section and can be exported as reports for audit evidence.

What auditors look at in practice🔗

The controls mapping table and compliance scans produce documentation. Auditors also ask for operational evidence — proof that the controls are not just configured but active and effective. The questions that come up repeatedly in Kubernetes compliance audits:

“Show me who has cluster-admin.”

kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

The answer should be a short list of named administrators — not service accounts, not broad groups like system:authenticated.

“Show me that privileged pods cannot run in production namespaces.”

kubectl get ns -o json | \
  jq '.items[] | select(.metadata.labels["pod-security.kubernetes.io/enforce"] != null) |
    {name: .metadata.name, enforce: .metadata.labels["pod-security.kubernetes.io/enforce"]}'

Every production namespace should show restricted. Namespaces without the label are unprotected and represent a finding.

“Show me the last 90 days of access to secrets in this namespace.”

This is where the audit log backend is queried. The query should return the audit events for verb: get, resource: secrets, namespace: myapp with usernames, timestamps, and source IPs. Without a centralised audit log retained for 90 days, this question cannot be answered.

“Show me evidence that your image signing policy is enforced.”

The Kyverno ClusterPolicy from Part 5 produces audit events when it rejects a pod. These events, combined with the policy definition itself in the GitOps repository, demonstrate that unsigned images cannot deploy.

“How do you know what changed and who changed it?”

The GitOps commit history. Every change to the cluster’s desired state is a git commit with author, timestamp, and diff. The Argo CD or Flux sync events correlate git commits to the time they were applied. This is the audit trail for configuration changes.

Closing the loop🔗

Compliance in Kubernetes is not a separate discipline from the security and operational practices covered in this series. It is the same practices, viewed through the lens of regulatory requirements and evidence production.

The security controls from Part 5 are the technical implementation of the access control and data protection requirements in NIS2, DORA, PCI-DSS, and HIPAA. The observability and audit logging from Part 6 are what turn those controls into verifiable evidence. The GitOps workflow is what makes change control traceable. The log retention setup determines how far back that evidence can be produced on demand.

The practical starting point for any organisation bringing a Kubernetes cluster into a regulated scope:

1. Run kube-bench or the Compliance Operator and document the current baseline
2. Map the gaps to the controls table above and prioritise by regulatory weight
3. Enable and retain Kubernetes API audit logs at the level and duration your framework requires
4. Confirm your log storage backend satisfies the immediate-accessibility requirement for your retention period (particularly PCI-DSS 3-month hot tier)
5. Document the incident response procedure that uses the cluster’s audit and application logs
6. Schedule quarterly reviews — compliance is a continuous state, not a one-time certification

Partly used sources — specific references for this part:

• NIS2 Directive (EU) 2022/2555 — European Parliament and Council (2022)
• DORA Regulation (EU) 2022/2554 — European Parliament and Council (2022)
• PCI DSS v4.0 — PCI Security Standards Council (2022)
• HIPAA Security Rule — 45 CFR Part 164 — US HHS
• CIS Kubernetes Benchmark — Center for Internet Security
• Kubernetes Best Practices I Wish I Had Known Before — Pulumi (2025, updated 2026)
• kubernetes-best-practices — Diego Lima, Apache-2.0