RHACS - Scans Your Containers So They Don't Get You Fired

That "we need security but can't break CI/CD" problem? This is Red Hat's attempt to solve it. RHACS is built on the bones of StackRox, which Red Hat bought in 2021 when they realized that telling customers to "just be careful" wasn't a viable security strategy for container deployments.

RHACS 4.8 dropped in July with some useful fixes - most notably they fixed Scanner V4 from randomly crashing Central pods with "invalid memory" errors. That particular bug was a real pain in production.

How It Actually Works (The Good and Bad)

RHACS has two main pieces: Central (the brain) and Sensors (the eyes). Central runs your web console, policy engine, and database. Sensors run on each cluster you want to monitor and phone home to Central with security data.

The architecture scales pretty well - I've seen it handle 200+ clusters without falling over, though we hit API throttling issues around 150 clusters when everyone was scanning images at once during a security incident. The 3% CPU overhead they claim is optimistic bullshit. We see more like 5-8% in production, sometimes worse when shit hits the fan. The Sensor talks to the Kubernetes API constantly, so if your API server is already struggling, you're fucked.

One thing that trips people up: RHACS integrates with Jenkins, GitLab, and GitHub Actions, but the CI/CD plugin quality varies wildly. The Jenkins plugin is solid. The GitHub Action works but documentation is sparse. GitLab integration exists but you're mostly on your own.

What It Covers (And What You Still Need To Handle)

RHACS handles three main areas: image scanning, cluster configuration hardening, and runtime threat detection. It works on OpenShift (best experience), EKS, GKE, AKS, and vanilla Kubernetes. You'll get better results on OpenShift because Red Hat can control more of the stack.

The image scanning catches most CVEs before they hit production. Runtime monitoring learns your app behavior and alerts on weird stuff - crypto mining, weird network connections, privilege escalation attempts. Cluster hardening checks your configs against CIS benchmarks and other standards.

What it doesn't do: network security (beyond basic monitoring), secrets management, or much help with compliance reporting beyond "here's what's broken." You'll still need something like Falco for deep runtime security or External Secrets Operator for proper secrets handling.

Speaking of pain points, let's talk money.

Those comparison tables are great for procurement meetings, but here's what actually happens when you deploy RHACS in production.

Image Scanning - Catches Most Stuff, Misses Some

Scanner V4 became the default in RHACS 4.7 and is a massive improvement over the old StackRox scanner. It generates proper SBOMs and supports CSAF VEX feeds, which actually helps with compliance instead of just checking boxes. The scanning coverage improved significantly - now catches most CVEs in base images, language-level dependencies (Node.js, Python, Java), and even some application-level issues.

What it still doesn't catch: zero-days (obviously), misconfigurations in your app code, and some language-specific vulnerabilities if your Dockerfile is weird. Scanner V4 also needs 50GB of storage for the vulnerability database, which surprised some folks during initial deployments. Budget for 100GB if you scan large repositories regularly.

The signing stuff mostly works now, unlike the previous clusterfuck implementation. RHACS 4.8 fixed the Cosign/sigstore integration so it doesn't randomly fail when validating signatures.

But most teams still aren't using image signing. It's one of those "we'll get to it someday" features that never happens until after an incident.

Another useful improvement in 4.8: enhanced vulnerability advisories now report both CVE IDs and RHSA (Red Hat Security Advisory) information separately. Previously, RHACS replaced CVE IDs with RHSA IDs once fixes were available, which was confusing as hell. Now you see both the vulnerability and the fix information clearly.

Cluster Hardening - Good Baseline, Needs Tuning

RHACS checks your cluster configs against CIS Kubernetes benchmarks, NIST standards, and other compliance frameworks. The checks are solid and catch common misconfigurations like overprivileged pods and missing network policies.

The new OpenShift Infrastructure Compliance in 4.8 is genuinely useful for OpenShift users, but it does add another operator to manage. It works with the OpenShift Infrastructure Compliance operator to assess compliance standards across your entire OpenShift fleet. The compliance reports are comprehensive but overwhelming - you'll get flagged for hundreds of issues on a fresh cluster.

The enhanced compliance reporting in 4.8 is a practical improvement: you get complete compliance reports even when some clusters fail during scheduled scans. This means you maintain security oversight of successfully scanned clusters instead of losing everything when one cluster acts up.

Reality check: You'll spend weeks tuning policies to match your actual environment. The default settings are paranoid, which is good for security but bad for getting work done.

Runtime Monitoring - Powerful But Noisy

RHACS learns what your applications normally do and alerts when they do something weird. It monitors process execution, network connections, file system changes, and privilege escalation attempts.

When it works, it's great - I've seen it catch crypto miners, reverse shells, and data exfiltration attempts. The external IP visibility in 4.8 is a game-changer for network security. It visualizes external IPs directly in the network graph dashboard - no more blind spots when tracking outbound connections. This feature is disabled by default (for obvious performance reasons), but once enabled, it shows external IPs in the Network Graph and includes detailed external IP information in Unauthorized Network Flow violations.

When it doesn't work: false positive hell. Applications that do weird but legitimate things (like Kubernetes operators or build tools) will trigger alerts constantly. Plan on 2-4 weeks of tuning allowlists after initial deployment.

Policy Engine - 375+ Ways to Break Your Deploy

RHACS ships with like 350+ built-in policies (I stopped counting after the first hundred broke our CI) covering everything from container configurations to runtime behavior. Most are reasonable, some are absurd (like flagging every container that runs as root, which breaks half of Helm charts).

The Policy as Code feature moved from tech preview to GA in 4.8. You can now manage RHACS policies as Kubernetes custom resources and integrate them into GitOps workflows with Red Hat GitOps (Argo CD). This is actually useful for teams that want policy management in their existing Git workflows, but you'll still need to understand both RHACS policy syntax and your application requirements.

RHACS 4.8 also introduced build-time network tools with support for Admin Network Policies (ANP) and Baseline Admin Network Policies (B/ANP). The connectivity mapping now understands these policies and correctly computes effective connectivity rules. The explainability feature helps identify which resources and rules are allowing or denying workload connectivity, which is genuinely helpful for troubleshooting network policy interactions.

Pro tip: Start with policies in "inform" mode, not "enforce." Otherwise you'll block legitimate deployments on day one. I learned this hard way when RHACS blocked our monitoring stack because it didn't like Prometheus scraping metrics.

Another gotcha: Don't upgrade Central and Sensors at the same time. We learned this during our 4.6 to 4.7 upgrade when mismatched versions caused Sensors to report duplicate alerts for 6 hours. Red Hat support said "yeah, that's a known issue" after we spent a day debugging it.

So here's what everyone really wants to know: