RHACS Compliance Implementation: Stop Panicking When Auditors Show Up

RHACS 4.8 Compliance:

What's Actually Fixed vs What's Still Broken

Look, RHACS 4.8 fixed some shit, but it's still not the magical compliance solution Red Hat sells you on.

I've been running it in production since the 4.8 GA release in July 2025, and here's what actually changed versus what's still a pain in the ass.

The compliance scanning used to fail with completely useless errors like "scan failed: internal error"

• turns out it was memory limits every damn time.

That's mostly fixed now

• the 4.8 release finally includes proper error reporting when scans fail. But the scanner still hits memory limits on larger clusters and dies silently. Pro tip: RHACS 4.8.1 has a memory leak in the network flow migration that killed our dev cluster during upgrade.

Pin to 4.8.3 or later.

What Compliance Standards Actually Work

Standards that work out of the box:

• CIS Kubernetes Benchmark
• CIS standards are solid.

RHACS gets about 90% of these right. The remaining 10% are edge cases where your environment doesn't match CIS assumptions

• NIST SP 800-190
• [NIST container guidelines](https://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.

SP.800-190.pdf) map well to RHACS capabilities, but expect to tune policies for weeks

Standards that need heavy customization:

• HIPAA
• Works but requires massive policy tuning.

Every healthcare org has different PHI classification rules

• PCI DSS
• PCI requirements are strict as hell.

RHACS helps with technical controls but won't handle your network segmentation headaches

• SOC 2
• Good for security criteria, useless for availability and processing integrity

What doesn't work:

• OpenSCAP on OpenShift
• SCAP integration is clunky.

The compliance operator works but generates different findings than RHACS native scanning, confusing your auditors

RHACS 4.8:

What Actually Got Better

OpenShift Infrastructure Compliance Actually Works Now
The infrastructure compliance operator finally graduated from tech preview hell. RHACS infrastructure scanning now works with the compliance operator without crashing every other scan.

But it's still slow as fuck

• budget 30 minutes per cluster.

Compliance Reports Don't Die When One Cluster Fails

This was a massive pain point. If any cluster in your fleet failed scanning, you'd get zero compliance reporting. 4.8 fixes this

• failed clusters get marked as "scan failed" instead of breaking everything.

Policy as Code Is Finally Stable
Policy as Code moved from "tech preview that will eat your homework" to "actually works in production." You can manage policies as Kubernetes custom resources and integrate with GitOps workflows.

The CRD validation is solid and won't accept broken policy configs anymore.

What RHACS Actually Collects (And What It Misses)

The compliance scanner grabs a shit-ton of data from your clusters, but understanding what it actually captures versus what auditors want to see is critical:

What it captures well:

• Docker daemon configs and runtime settings
• solid coverage here

• Kubernetes RBAC policies and access patterns

• excellent for auditor questions

• Network policies and pod-to-pod communication rules

• Container image vulnerability data from Stackrox Scanner V4

• way faster than the old scanner

• Pod Security Standards compliance across namespaces

What it struggles with:

• File system permissions on worker nodes

• hit or miss depending on your node setup

• Runtime behavior analysis generates tons of false positives in microservice environments

• Supply chain verification works great until you have private registries with custom cert chains

What auditors want but RHACS doesn't provide:

• Data flow diagrams showing where PHI/PCI data actually goes

• Change management audit trails for infrastructure modifications

• Business process documentation linking technical controls to compliance requirements

The scanner is a resource hog on big clusters.

Had to bump memory limits after it kept crashing on our 400+ node production cluster.

Regulatory Reality Check

**HIPAA

• Healthcare's Special Hell:**
  HIPAA technical safeguards sound straightforward until you realize every hospital defines PHI differently.

RHACS can enforce encryption and access controls, but you'll spend more time arguing with your legal team about data classification than configuring policies.

Real implementation time: 4-6 months, not the 6-8 weeks consultants promise.

Most of that time is figuring out which workloads actually process PHI versus which ones just might.

**PCI DSS

• Payment Card Nightmare:**
  PCI DSS requirements are brutal.

Network segmentation requirements mean your microservices architecture just became a compliance clusterfuck. RHACS helps with vulnerability scanning and access control, but won't solve your network isolation headaches.

Expect your PCI audit to take 6 months longer than planned because your auditor will question every network policy exception.

**SOC 2

• The Documentation Grind:**
  SOC 2 Trust Services Criteria are about demonstrating control effectiveness over time.

RHACS collects great technical evidence, but your auditor wants process documentation and change management records.

Type II audits are 12 months of documentation hell. RHACS automates evidence collection but someone still needs to write all the process documents auditors demand.

Enterprise Integration Hell

Automated Evidence Collection (That GRC Teams Hate):

RHACS generates tons of compliance evidence, but in formats that don't play nice with enterprise GRC tools.

You'll build custom export scripts for every audit cycle. ServiceNow GRC integration exists but requires custom API work.

Continuous Monitoring (That Creates Alert Fatigue):
Real-time compliance alerting sounds great until you're getting 200 alerts per day for policy violations that don't actually matter.

Tuning takes months and your SecOps team will hate you.

Third-Party Integration (API Hell):
Integrating with Splunk, Archer, or other GRC platforms requires custom development.

Budget 3-4 weeks because Service

Now's GRC API documentation was clearly written by someone who's never used it. Half the endpoints don't work as documented, and plan for ongoing maintenance when vendors change their APIs.

Now that you understand what actually works and what's broken in RHACS 4.8, let's look at the real implementation timelines for each compliance framework. Spoiler alert: they're all longer than Red Hat claims.

I've done this dance five times across different regulatory frameworks. Here's what actually works versus the bullshit Red Hat tells you in sales demos. Skip the marketing slides and focus on these implementation realities.

HIPAA Implementation: Prepare for Legal Hell

HIPAA isn't just a technical problem - it's a legal and organizational clusterfuck. I spent 6 months on one HIPAA implementation, and 4 months of that was arguing with lawyers about PHI classification. The PCI implementation at my last company took 14 months because the auditor decided halfway through that our microservices needed dedicated network segments. Classic scope creep.

What you'll actually spend time on:

1. PHI identification (2-3 months) - Figuring out which workloads actually process PHI
2. Policy tuning (1-2 months) - Getting RHACS policies to match your security requirements
3. Legal approval (1-2 months) - Getting lawyers to sign off on technical controls
4. Documentation (ongoing) - Writing process docs that auditors actually want

RBAC that actually works:

## Realistic HIPAA RBAC - not the toy example Red Hat shows
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: phi-limited-access
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
  resourceNames: ["phi-*"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
  resourceNames: ["phi-*"]
## No create, update, delete without MFA

Technical controls that actually matter:

RHACS policy enforcement can automate some HIPAA technical safeguards, but you'll still need manual processes for the stuff RHACS can't handle.

• Encryption in Transit: TLS 1.2+ enforcement works well through admission controllers
• Encryption at Rest: RHACS validates persistent volume encryption but can't check if your storage keys are properly managed
• Access Controls: RBAC policies work but you'll manually audit user access quarterly
• Audit Logging: RHACS audit trails are good but insufficient - you need Kubernetes audit logs too

Real HIPAA scanning command:

## What actually works for HIPAA scanning
roxctl compliance scan --standard=CIS_Kubernetes_v1.5.1 \
  --cluster=production \
  --output-format=json > scan_results.json

## No HIPAA-specific standard exists - use CIS + custom policies

PCI DSS: Network Segmentation Nightmare

PCI DSS is fucking brutal. The network segmentation requirements will make you question your microservices architecture. I've seen PCI implementations take 12+ months because nobody planned for the isolation requirements.

Network segmentation reality check:

PCI auditors are paranoid about cardholder data environment (CDE) isolation. Network policies help but won't solve your fundamental architecture problems.

## PCI network policy that actually works (but breaks everything else)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: cde-isolation
  namespace: payment-processing
spec:
  podSelector:
    matchLabels:
      pci-scope: "cde"
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          pci-zone: "payment-gateway"
    ports:
    - protocol: TCP
      port: 8443
  egress:
  - to: []  # Deny all egress by default
    ports: []
## This will break service mesh, monitoring, and probably your sanity

PCI vulnerability scanning reality:

PCI Requirement 6 vulnerability timelines are aggressive. RHACS Scanner V4 is faster than the old scanner but won't save you from organizational dysfunction.

• Critical CVEs: 30 days to remediate (good luck with legacy Java apps)
• High CVEs: 90 days (more realistic but still tight)
• Quarterly external scans: Required and expensive ($10-50K annually)
• Change management: Every CDE deployment needs vulnerability approval

PCI approval workflows are slow as hell. Budget months, not weeks, for anything touching card data.

SOC 2: Documentation Hell Disguised as Security

SOC 2 Type II is 12 months of proving your controls work consistently. RHACS provides good technical evidence, but you'll spend more time writing process documents than configuring security.

What SOC 2 auditors actually want:

SOC 2 auditors care more about process documentation than technical controls. RHACS helps with the security criteria, but you'll write policies and procedures for everything else.

Controls that RHACS handles well:

• CC6.1: Logical access controls through RBAC and network policies
• CC6.7: Vulnerability management through continuous scanning
• CC6.8: Security monitoring through policy enforcement

Controls RHACS can't help with:

• Change management processes (you need written procedures)
• Vendor risk management (manual assessment and documentation)
• Business continuity planning (RHACS doesn't write your disaster recovery plan)
• Employee background checks (obviously)

The real SOC 2 implementation timeline:

• Months 1-3: Write policies and procedures (most of your time)
• Months 4-6: Implement technical controls (RHACS configuration)
• Months 7-18: Collect evidence and prove effectiveness
• Month 19+: Audit preparation and remediation

RHACS automates evidence collection for security controls, but someone still needs to document all the business processes. Plan accordingly.

OpenSCAP Integration: When the Compliance Operator Actually Works

OpenSCAP integration with the OpenShift Compliance Operator is hit or miss. When it works, it's great. When it doesn't, you'll spend days debugging scan failures.

OpenSCAP that actually works:

## Compliance operator config that won't crash
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: moderate-compliance
spec:
  profiles:
  - name: ocp4-moderate  # Don't use 'high' profiles - they're broken
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
  settingsRef:
    name: default
    kind: ScanSetting
    apiGroup: compliance.openshift.io/v1alpha1

What you'll spend time on:

• Debugging why compliance operator pods crash (1-2 weeks)
• Tuning scan schedules so they don't kill your clusters (ongoing)
• Explaining to auditors why RHACS and OpenSCAP give different results (every audit)

Monitoring That Won't Drive You Insane

Continuous compliance monitoring sounds great until you're getting 200 alerts per day. Here's how to set up monitoring that actually helps instead of creating alert fatigue.

Realistic compliance alerting:

## Prometheus rules that won't spam you
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: compliance-violations-sane
spec:
  groups:
  - name: compliance.rules
    rules:
    - alert: CriticalComplianceViolation
      expr: increase(stackrox_policy_violations_total{severity="CRITICAL"}[1h]) > 5
      labels:
        severity: warning  # Not critical - you'll get alert fatigue
      annotations:
        summary: "Multiple critical compliance violations"
        description: "{{ $value }} critical violations in last hour"
    
    - alert: ComplianceScanFailed
      expr: up{job="stackrox-scanner"} == 0
      for: 30m  # Give it time to recover
      labels:
        severity: critical
      annotations:
        summary: "Compliance scanning is down"

Evidence collection reality check:

RHACS collects tons of evidence, but auditors want it in specific formats:

• Prometheus metrics for compliance trends (auditors love charts)
• Grafana dashboards showing compliance posture over time
• Raw audit logs stored for 7+ years (expensive)
• Custom export scripts for every GRC platform your company uses

Enterprise GRC Integration Hell

Every enterprise has different GRC tools, and none of them speak RHACS natively. You'll build custom integrations for everything.

Budget for these integrations:

• ServiceNow GRC: weeks of development
• Splunk: log shipping and parsing takes time
• Archer GRC: weeks (their APIs suck)
• Whatever custom tool your compliance team bought: longer than you think

The good news: Once you build these integrations, compliance reporting becomes mostly automated. The bad news: You'll maintain these integrations forever as vendors change APIs.

Reality check: RHACS is a solid compliance tool, but it's not magic. Plan for 6-12 months of implementation and tuning before you have a compliance program that actually works.

Now that you've seen the implementation reality, let's address the questions everyone has but is too embarrassed to ask. These are the real-world problems you'll hit that nobody talks about in the official documentation.