Compliance and auditing

Understanding Compliance in OpenShift

Compliance in OpenShift is about proving—consistently and repeatably—that your cluster and workloads follow specific security, regulatory, and organizational rules. Security controls alone are not enough; compliance requires:

• Defined requirements (e.g., PCI-DSS, HIPAA, SOC 2, internal standards)
• Technical and process controls that enforce those requirements
• Evidence and documentation that those controls are in place and effective

OpenShift does not make a cluster “compliant” by itself. Instead, it provides:

• Features that help implement controls (RBAC, SCCs, image policies, etc.)
• Tools that generate and collect evidence (logs, reports, configuration)
• Integrations with external governance, risk, and compliance (GRC) tools

Your role is to map regulatory requirements to OpenShift capabilities and operational practices, then maintain that mapping over time.

Key Compliance Domains for OpenShift Clusters

Depending on your industry, OpenShift often appears in compliance scopes such as:

• Infrastructure security: Host hardening, network segmentation, patching.
• Platform configuration: Kubernetes/OpenShift security baselines, access control, encryption.
• Application security: Image provenance, vulnerability management, runtime restrictions.
• Data protection: Encryption at rest and in transit, data locality, backup and retention.
• Operational process: Change management, incident response, monitoring, and audit logging.

Common external frameworks and benchmarks that influence OpenShift deployments include:

• CIS Benchmark for Kubernetes / OpenShift: Prescriptive hardening and configuration checks.
• NIST 800-53 / 800-190: Controls for federal and containerized environments.
• PCI-DSS: For payment data; focuses on segmentation, logging, access control, and patching.
• HIPAA / GDPR: For personal/health data; focuses on privacy, access control, and data handling.

OpenShift’s compliance story is largely about how cluster configuration, security policies, and operational procedures align with these frameworks.

OpenShift Features Relevant to Compliance

Several OpenShift components and platform services are particularly important from a compliance perspective:

• Cluster configuration and policies
• Cluster-wide settings (authentication, encryption, audit policies)
• Admission controls and policy enforcement (via Operators, webhooks, Gatekeeper/Kyverno, etc.)
• Security policies such as Security Context Constraints (SCCs) and network policies
• Image and supply-chain security
• Image registries with access controls
• Image signature and trust policies
• Vulnerability scanning integrations and policies that block known-vulnerable images
• Data protection
• Encryption for control plane traffic and storage backends
• Integration with external KMS/HSM for key management
• Storage configuration and backup strategies aligned with retention and recovery requirements
• Observability and auditability
• API server audit logs
• Cluster and workload logs
• Metrics and alerts that demonstrate continuous monitoring

In most regulated environments, auditors will expect you to show how you have configured and monitored these capabilities—not just that they exist.

OpenShift Compliance Tooling and Benchmarks

While OpenShift can integrate with many external GRC and scanning tools, there are several common approaches and components specifically used for compliance posture:

Compliance Operator (Red Hat OpenShift)

In many OpenShift environments, the Compliance Operator is the central tool for formal compliance assessments. It provides:

• Predefined profiles aligned with standards, such as:
• CIS benchmarks
• NIST-based profiles (e.g., moderate-high baselines)
• Vendor-specific security baselines
• Machine-readable rules that check:
• OS-level configuration on cluster nodes
• Kubernetes/OpenShift control plane configuration
• Certain workload and policy settings
• Automated scans:
• Scheduled or on-demand
• Cluster-wide or focused on subsets of nodes
• Reports and remediation:
• Results stored as Kubernetes resources
• Optional remediation manifests that can be applied to fix issues
• Structured output (e.g., XCCDF) that auditors can consume

Typical workflow:

1. Select a profile that aligns with your required standard.
2. Run a scan across the cluster.
3. Review results for failed rules and their severities.
4. Apply remediations (manually or automatically) where appropriate.
5. Re-scan to verify that issues are resolved.
6. Export reports for audits and documentation.

Key point: the operator helps you prove compliance (or non-compliance) objectively and repeatedly.

Node and OS-Level Compliance

OpenShift typically runs on RHEL, RHCOS, or similar enterprise Linux variants. Compliance often requires:

• OS-level hardening (e.g., disabling unused services, applying kernel parameters)
• Configurations for logging, time synchronization, and file permissions
• FIPS mode and cryptographic policies

The Compliance Operator and base OS content often include:

• SCAP content for RHEL/RHCOS
• Rules ensuring FIPS mode is enabled
• Checks for required system services and configurations

These checks ensure that both the cluster and underlying nodes meet your security baseline, which is critical for many regulatory frameworks.

Audit Logging in OpenShift

Auditing is about generating a trustworthy record of what happened in the cluster—who did what, when, and from where. For compliance, this audit trail needs to be complete, tamper-resistant, and retained according to policy.

Kubernetes API Audit Logs

The Kubernetes API server on OpenShift can be configured to:

• Capture API requests and responses such as:
• oc or kubectl commands
• Changes to cluster resources (e.g., creating pods, modifying RBAC)
• Authentication attempts
• Filter logs by:
• Request type (read vs write)
• User or group
• Resource type and namespace
• Persist logs:
• To local files
• Via log forwarding to centralized systems

From a compliance viewpoint:

• These logs provide evidence of administrative actions (e.g., who granted which role, who deployed which resource).
• They support forensic analysis after security incidents.
• They can be correlated with external identity providers (e.g., LDAP, SSO) to trace actions to individuals.

Typical tasks for compliance:

• Define an audit policy that captures relevant events without overwhelming storage.
• Ensure audit logs are centralized and protected from modification.
• Validate log retention, rotation, and access controls.

Cluster and Application Logging

Beyond API audits, compliance often requires:

• System logs: Node logs, container runtime logs, OpenShift component logs.
• Application logs: Business and security events from user workloads.

OpenShift logging solutions (built-in or external) are used to:

• Collect and forward logs to centralized platforms (e.g., Elasticsearch, Loki, Splunk, SIEM).
• Separate duties:
• Operations teams manage the log platform.
• Security/compliance teams query and review logs.
• Implement retention policies:
• Different retention periods for security vs operational logs.
• Legal holds and export for investigations.

Audit relevance:

• Logs help prove that security controls detect suspicious activity.
• They provide the raw data for periodic review and continuous monitoring.
• They form part of the “evidence package” for audits.

Identity, Access, and Change Traceability

From a compliance perspective, it is not enough to have RBAC and authentication; you must show traceability:

• Every significant action should be attributable to a specific user, group, or service account.
• Changes to permissions and security policies must be auditable.

Key practices:

• Integrate OpenShift authentication with an enterprise identity provider:
• So that actions in audit logs can be linked to real persons or managed identities.
• Use fine-grained RBAC:
• Minimize use of cluster-admin-level access.
• Create separate roles for operations, security, and development teams.
• Require change records for sensitive operations:
• Tie actions in OpenShift (e.g., creating a new ClusterRole) to tickets in your change management system.
• Use Git-based configuration (GitOps) so changes are version-controlled and reviewable.

For auditing:

• Provide mapping documentation from roles/groups to job functions.
• Demonstrate that production-access changes go through an approval workflow.
• Show that service accounts have only the permissions they need.

Evidence Collection and Reporting

Compliance is as much about evidence as it is about technical controls. In OpenShift environments, useful evidence includes:

• Configuration snapshots
• Exported manifests for critical resources: RBAC objects, SCCs, network policies, etc.
• Cluster configuration resources (e.g., APIServer, OAuth, Image, Network objects).
• Scan results and reports
• Output from the Compliance Operator or other scanning tools.
• Vulnerability reports for container images and runtimes.
• Log excerpts and dashboards
• Screenshots or exports showing monitoring dashboards and alerts.
• Queries demonstrating how security or access logs are reviewed.
• Procedural documentation
• Runbooks for handling security incidents or failed compliance checks.
• SOPs for patching, upgrades, and vulnerability remediation.

Good practices:

• Automate evidence collection where possible (e.g., periodic export of scan results).
• Standardize report formats for auditors (PDF, CSV, structured reports).
• Ensure evidence includes timestamps, version information, and scope of what was checked.

Continuous Compliance and Drift Management

Compliance is not a one-time event. OpenShift clusters are dynamic: nodes are added, Operators are upgraded, workloads are deployed and removed. Maintaining compliance means:

• Detecting drift:
• Periodic or continuous scans (Compliance Operator, policy engines).
• Alerts if critical settings diverge from the baseline.
• Enforcing desired state:
• Using GitOps tools to ensure cluster configuration matches audited manifests.
• Applying remediation manifests for known-mandatory rules.
• Handling upgrades and changes:
• Re-validating compliance after cluster upgrades, node OS updates, or new Operators.
• Including compliance checks in CI/CD pipelines for both platform and application changes.

Typical patterns:

• Run nightly or weekly compliance scans; treat failures like failing tests.
• Integrate compliance results into dashboards for security and operations teams.
• Add policy checks to admission control (e.g., reject non-compliant workloads at deploy time).

Working with Auditors in an OpenShift Environment

When preparing for or undergoing an audit with OpenShift in scope, it helps to:

• Define scope early:
• Which clusters, environments (dev/test/prod), and namespaces are in-scope.
• Which services are managed by your team vs a cloud provider or managed OpenShift service.
• Translate controls to platform terms:
• Map each requirement to:
• OpenShift features (RBAC, SCC, network policies)
• External tools (SIEM, scanning, key management)
• Operational processes (change management, incident response)
• Prepare demonstration scenarios:
• Show how a user is created and granted access, and how it appears in logs.
• Show how a non-compliant configuration is detected and remediated.
• Show how you prove that only signed and scanned images are allowed.

Common deliverables:

• A control mapping document linking each requirement to:
• A specific OpenShift configuration or feature.
• Evidence artifacts (scan report IDs, log queries, change tickets).
• A runbook describing how compliance is continuously maintained:
• Who reviews scan results and logs.
• How exceptions are tracked and remediated.
• How new clusters or workloads are onboarded to the compliant baseline.

Practical Recommendations for Beginners

For teams new to OpenShift and compliance:

1. Start with a baseline benchmark
   Choose a reasonable security benchmark (e.g., vendor-provided baseline or CIS) and use the Compliance Operator to understand your initial posture.
2. Centralize logs and identify “must-keep” events
   Ensure API audit logs and key system logs are collected centrally and retained long enough to satisfy regulatory requirements.
3. Document your security and compliance assumptions
   Clarify which controls are handled by infrastructure providers, which by the OpenShift platform, and which by application teams.
4. Integrate compliance into normal operations
   Treat failed compliance checks like production incidents. Make remediation part of regular sprints or maintenance windows.
5. Practice exporting and presenting evidence
   Before a real audit, simulate one: gather reports, logs, and configuration snapshots and validate that they answer typical auditor questions.

By combining OpenShift’s built-in features with structured policies, logging, and continuous scans, you can move from “hoping we’re secure” to demonstrable, repeatable compliance.