🧱 StackRox Kubernetes Security Platform (Open Source) and RHACS

Intro: StackRox is now best understood as the upstream open-source project behind Red Hat Advanced Cluster Security for Kubernetes (RHACS). This page explains what the platform is, what became open source, what still differs in enterprise practice, and how to install and use it in a modern Kubernetes security program.

What StackRox is

StackRox is a Kubernetes-native security platform that covers build, deploy, and runtime for containerized workloads. In practical terms it sits between:

• image and deployment policy checks;
• cluster risk and posture visibility;
• network graph and baseline analysis;
• runtime and policy violations;
• compliance and reporting workflows.

Historically people often described it as “Kubernetes security posture plus runtime plus policy plus vulnerability context in one platform.” That is still roughly the right mental model.

What changed after the Red Hat acquisition

The careful answer

The broad statement “StackRox became fully free and preserved all enterprise functionality unchanged” is too strong.

The practical answer

A more accurate framing is:

• StackRox is the upstream open-source project;
• RHACS is the Red Hat productized distribution and remains the enterprise offering around that upstream;
• a large amount of the platform capability is available in the open project, but production buyers still care about packaging, support, release channels, operator workflows, OpenShift alignment, and enterprise lifecycle expectations.

Use this phrasing in the KB and in interviews:

“StackRox is the open-source upstream. RHACS is the Red Hat distribution and enterprise packaging.”

Why Product Security and Platform teams care

StackRox/RHACS is useful when you want one Kubernetes-native control plane for questions like:

• which deployments are riskiest right now;
• which workloads violate policy;
• which images are pulling in critical CVEs;
• which services talk to unexpected destinations;
• which clusters or namespaces are drifting from a secure baseline;
• which deploy-time settings should be blocked before rollout.

That makes it especially useful for:

• platform security teams;
• Kubernetes security engineers;
• Product Security teams that need workload context, not only IaC scanning;
• organizations that want policy-backed conversations with engineering instead of isolated scanner output.

Core architectural model

At a high level the platform is split into:

• Central — main backend, UI, API, policy evaluation, risk and findings aggregation;
• Scanner — image scanning and vulnerability context;
• Sensor — cluster-aware control-plane component;
• Collector — runtime and node/workload telemetry collection;
• Admission Controller — deploy-time prevention path.

A practical mental model:

What this means operationally

If you deploy StackRox well, the platform can answer three different questions with one shared context:

1. What is risky?
2. What is violating policy?
3. What is actually running and talking right now?

That shared context is one of the strongest reasons teams pick it.

What risks StackRox/RHACS helps reduce

1. Risky workload configuration

Examples:

• privileged containers
• host networking / host PID / host IPC
• missing resource limits
• dangerous capabilities
• mutable images or dangerous image sources

2. Weak image hygiene

Examples:

• known CVEs in runtime images
• risky base images
• poor image provenance visibility
• deployments using stale or vulnerable images

3. Poor network understanding

Examples:

• unknown east-west communication
• unexpected public or external destinations
• missing or weak Kubernetes NetworkPolicies
• policy gaps between intended and actual traffic

4. Weak deploy-time controls

Examples:

• allowing clearly noncompliant workloads into a cluster
• missing admission guardrails
• lack of “fail before deploy” checks for Kubernetes manifests and images

5. Runtime and policy violations

Examples:

• suspicious runtime behavior that maps to built-in or custom policies
• anomalous network flows
• policy violations by namespace, deployment, or cluster

Where it fits relative to other tools

A strong modern pattern is:

• StackRox/RHACS for shared platform visibility, risk ranking, policy, and Kubernetes-specific operating context;
• Falco or Tetragon if you need a more specialized runtime-detection layer;
• Trivy/Syft/Grype earlier in CI or artifact pipelines.

Installation patterns

Option 1 — Quick Helm install (good for lab or evaluation)

See: official StackRox GitHub README and docs.

/bin/bash <(curl -fsSL https://raw.githubusercontent.com/stackrox/stackrox/master/scripts/quick-helm-install.sh)

This quick path:

• adds the Helm repository;
• installs central services;
• creates an init bundle;
• installs secured-cluster services on the same cluster.

Use case

Good for:

• lab environments;
• product evaluation;
• quick hands-on familiarization.

Not ideal for

• hardened production rollout;
• controlled ingress/TLS patterns;
• teams that need explicit secrets, storage, exposure, and cluster-onboarding decisions.

Option 2 — Manual Helm install (better for controlled rollout)

Step 1 — Add the Helm repo

helm repo add stackrox https://raw.githubusercontent.com/stackrox/helm-charts/main/opensource/
helm repo update
helm search repo stackrox

Step 2 — Generate a strong admin password

export ROX_ADMIN_PASSWORD="$(openssl rand -base64 20 | tr -d '/=+')"

Step 3 — Install Central Services

helm upgrade --install -n stackrox --create-namespace stackrox-central-services   stackrox/stackrox-central-services   --set central.adminPassword.value="${ROX_ADMIN_PASSWORD}"

Step 4 — Pick a cluster name and Central endpoint

export CLUSTER_NAME="prod-cluster-1"
export CENTRAL_ENDPOINT="central.stackrox.svc:443"

Step 5 — Generate an init bundle

echo "$ROX_ADMIN_PASSWORD" | kubectl -n stackrox exec -i deploy/central -- bash -c 'ROX_ADMIN_PASSWORD=$(cat) roxctl --insecure-skip-tls-verify central init-bundles generate stackrox-init-bundle --output -' > stackrox-init-bundle.yaml

Step 6 — Install Secured Cluster Services

helm upgrade --install -n stackrox --create-namespace stackrox-secured-cluster-services   stackrox/stackrox-secured-cluster-services   -f stackrox-init-bundle.yaml   --set clusterName="$CLUSTER_NAME"   --set centralEndpoint="$CENTRAL_ENDPOINT"

Minimum lab deployment you can explain in an interview

Use this narrative:

1. install Central and Scanner;
2. generate an init bundle;
3. onboard one or more clusters with Sensor / Collector / Admission Controller;
4. connect your registry;
5. import or tune policies;
6. review risks, vulnerabilities, deployments, and violations in the UI;
7. add CI checks with roxctl image check and roxctl deployment check.

That is the minimum end-to-end lifecycle story.

Basic configuration that matters first

1. Exposure and TLS

For production, avoid leaving Central on an evaluation-grade self-signed path longer than necessary.

Baseline expectation:

• expose Central behind a controlled ingress or load balancer;
• use organization-managed TLS;
• restrict admin exposure;
• avoid broad internet exposure unless explicitly required.

2. Authentication and roles

Do not leave only the bootstrap admin mindset in place.

Early hardening steps:

• wire in SSO/identity provider where possible;
• create role-scoped access for platform, security, and read-only consumers;
• reduce who can alter policy vs only view findings.

3. Registry integrations

Connect the registries that actually matter:

• ECR
• Docker Hub
• Quay
• Artifactory
• Nexus
• ACR / GCR / GAR where relevant

This unlocks image metadata, layer visibility, and scan-backed policy decisions.

4. Admission Controller strategy

Start in a safer rollout order:

1. observe / alert
2. tune policies
3. only then enable blocking for the highest-confidence controls

Do not begin with a broad “block everything risky” posture unless you already understand workload variance and exemptions.

5. Network graph and baseline usage

Use it to:

• identify unexpected east-west flows;
• export baseline-informed network policy starting points;
• decide where to alert on anomalous flows before enforcing hard blocks.

CI and shift-left usage with roxctl

One of the most practically useful capabilities is using roxctl in CI or pre-deploy workflows.

Check deployment YAML against policies

export ROX_ENDPOINT=stackrox.example.internal:443
roxctl deployment check --file=deployment.yaml -o table

Check an image against policy

export ROX_ENDPOINT=stackrox.example.internal:443
roxctl image check --image=registry.example.com/team/app:1.4.2 -o table

Get scan results as JSON

export ROX_ENDPOINT=stackrox.example.internal:443
roxctl image scan --image registry.example.com/team/app:1.4.2 --force

Why this matters

This turns StackRox/RHACS from “a portal security people use” into:

• a CI gate;
• a manifest review step;
• an image triage source;
• a policy-backed conversation with engineering.

Example findings you will typically see

These are illustrative examples normalized to match official RHACS concepts and UI terms.

Example 1 — Privileged container deploy-time violation

Policy: Privileged Container
Entity: Deployment/payments-api
Type: DEPLOYMENT
Severity: HIGH
Lifecycle stage: DEPLOY
Cluster: prod-cluster-1
Namespace: payments
Message: Container 'api' is configured to run as privileged
Suggested action: remove privileged mode, review required capabilities, enforce admission blocking after rollout tuning

Example 2 — Risky image with fixable CVEs

Deployment: billing-worker
Cluster: prod-cluster-1
Namespace: finance
Image: registry.example.com/billing/worker:2.8.0
Top issues:
- Critical CVEs: 3
- Fixable CVEs: 11
- Runtimes affected: 2
- Dockerfile exposure: package manager layer introduces vulnerable libraries
Suggested action:
- rebuild on patched base image
- rerun image scan
- verify deployment risk drops after rollout

Example 3 — Anomalous network flow / baseline deviation

Policy: Network Baseline Violation
Entity: Deployment/reporting-api
Type: DEPLOYMENT
Severity: MEDIUM
Observed flow: reporting-api -> 198.51.100.25:443
Expected baseline: internal-only egress to approved SaaS endpoints
Suggested action:
- verify legitimate third-party dependency
- add to baseline only if justified
- otherwise tighten egress controls or NetworkPolicy

Example 4 — Build-time image policy failure in CI

roxctl image check --image registry.example.com/team/app:1.4.2 -o table

POLICY                              SEVERITY   RESULT
No Latest Tag                       MEDIUM     PASS
Fixable Critical CVEs               CRITICAL   FAIL
Docker CIS 4.1 Non-root User        HIGH       FAIL

Typical UI paths and what to do there

Dashboard

Use for:

• top risky deployments;
• violations by cluster;
• active violations over time;
• quick severity trend review.

Risk

Use for:

• prioritization;
• ranking deployments by risk;
• deciding where the next engineering fix should go.

Violations

Use for:

• policy-driven triage;
• explaining why something is risky;
• pivoting from an alert to the affected deployment/cluster/namespace.

Vulnerability Management

Use for:

• image issues and fixability;
• riskiest images and deployments;
• CVE export and remediation planning.

Network Graph / Network Baseline

Use for:

• east-west understanding;
• anomaly review;
• policy generation starting points.

Compliance

Use for:

• benchmark and evidence reporting;
• cluster / namespace / control drill-down.

Integration with current infrastructure

With registries

Most teams should begin by integrating:

• the primary runtime registry;
• the build-time registry used by CI;
• any “golden image” or platform registry.

This gives you:

• image metadata;
• Dockerfile layer visibility;
• scan-backed image policies before and after deploy.

With CI/CD

Typical pattern:

• roxctl image check after image build;
• roxctl deployment check before deployment;
• fail only on a narrow high-confidence set at first;
• route full JSON output to artifact retention or security triage.

With Slack / PagerDuty / JIRA / webhooks

Use notifiers and webhooks sparingly. A good pattern is:

• high-confidence deploy/runtime violations → alerting/ticketing;
• informational drift or medium-risk image findings → portal/SIEM review.

With existing network policy work

Use the network graph and baseline functions as a generator and review aid, not as a replacement for understanding traffic flows yourself.

Common mistakes and how to avoid them

Mistake 1 — Treating it like “just another scanner”

Fix:

• use risk, policy, network, and deploy-time capabilities too.

Mistake 2 — Enabling blocking too early

Fix:

• start in observe mode, then tune, then block.

Mistake 3 — Only onboarding one lab cluster and never wiring registries

Fix:

• connect the registries and at least one realistic production-like cluster.

Mistake 4 — Forgetting CI usage

Fix:

• operationalize roxctl image check and roxctl deployment check.

Mistake 5 — Overclaiming open-source versus enterprise parity

Fix:

• explain clearly: upstream open source exists; RHACS is the Red Hat distribution and enterprise packaging.

Official visual references worth reviewing

Instead of embedding stale screenshots, use these living official references:

• StackRox docs hub: https://www.stackrox.io/docs/
• StackRox GitHub repository: https://github.com/stackrox/stackrox
• RHACS architecture docs: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/
• RHACS operating docs (risk, violations, vulnerability management, network graph): https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/

These pages include architecture diagrams, dashboard examples, and current UI concepts that will age better than frozen screenshots in the KB.

Practical recommendation for this KB

Use StackRox/RHACS when you need:

• Kubernetes-native security context;
• risk ranking of workloads;
• policy violations across build, deploy, and runtime;
• network graph / network baseline workflows;
• a shared UI for platform + product security conversations.

Do not position it as:

• a drop-in replacement for all runtime detection tools;
• a pure IaC scanner;
• a promise that “open source means identical enterprise experience.”

It is best positioned as a Kubernetes security platform with strong policy/risk/cluster context and useful runtime-adjacent visibility.