# StackRox Kubernetes Security Platform Guide > **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: | Component | Primary job | | -------------------- | ----------------------------------------------------------- | | Central | UI, API, policy engine, risk aggregation, cluster inventory | | Scanner | Image/component/CVE analysis | | Sensor | Watches cluster state and policy-relevant events | | Collector | Runtime/node/workload telemetry collection | | Admission Controller | Blocks or flags policy-breaking workloads at deploy time | ### 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 | Tool type | Role next to StackRox | | ---------------------- | ----------------------------------------------------------------------------------------------------- | | Trivy / Grype / Clair | narrower scanning utilities, often used earlier in CI or registry workflows | | Falco / Tetragon | deeper runtime-specialist layers for syscall/eBPF-centric detection and enforcement | | Kube-bench / Kubescape | posture and benchmark-centric layers | | OPA / Kyverno | policy engines and enforcement primitives that may complement or overlap parts of deploy-time control | 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. ```bash /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 ```bash 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 ```bash export ROX_ADMIN_PASSWORD="$(openssl rand -base64 20 | tr -d '/=+')" ``` ### Step 3 — Install Central Services ```bash 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 ```bash export CLUSTER_NAME="prod-cluster-1" export CENTRAL_ENDPOINT="central.stackrox.svc:443" ``` ### Step 5 — Generate an init bundle ```bash 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 ```bash 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 ```bash export ROX_ENDPOINT=stackrox.example.internal:443 roxctl deployment check --file=deployment.yaml -o table ``` ### Check an image against policy ```bash 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 ```bash 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: * StackRox GitHub repository: * RHACS architecture docs: * RHACS operating docs (risk, violations, vulnerability management, network graph): 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index-1/stackrox-kubernetes-security-platform-guide.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.