Step-by-Step Guide to StackRox ACS Implementation

Implementing StackRox / Red Hat Advanced Cluster Security (ACS) involves a two-step deployment model based on its architecture:

  1. The Central Cluster (The Hub): Where you install the UI dashboard, the database, and the image scanners.
  2. The Secured Clusters (The Spokes): Where you install the local sensors, admission controllers, and node collectors. (Note: Your Hub cluster can also be configured as a Spoke to protect itself).

Here is the production-ready implementation guide using the recommended Kubernetes Operator method on OpenShift, followed by a GitOps/Helm Blueprint for scaling out to multiple secured clusters.

Phase 1: Deploying the Central Services (The Hub)

Step 1: Install the ACS Operator
  1. Log into your OpenShift Web Console.
  2. Navigate to Operators -> OperatorHub and search for Advanced Cluster Security.
  3. Click Install, accepting the default namespace (rhacs-operator) and automatic update strategy.
Step 2: Create the Central Custom Resource

Once the operator is active, you must provision the Central instance. Switch to the stackrox namespace (create it if it doesn’t exist) and apply the following manifest:

YAML

apiVersion: platform.stackrox.io/v1alpha1
kind: Central
metadata:
name: stackrox-central
namespace: stackrox
spec:
central:
db:
persistence:
persistentVolumeClaim:
claimName: central-db
persistence:
persistentVolumeClaim:
claimName: stackrox-central-data
exposure:
route:
enabled: true # Automatically provisions an OpenShift Route for the dashboard
scanner:
analyzer:
replicaCount: 3
Step 3: Retrieve your Credentials

After a few minutes, the database and dashboard pods will spin up. Retrieve the auto-generated admin password and the web console URL from your cluster:

Bash

# Get the admin password
oc -n stackrox get secret central-htpasswd -o go-template='{{index .data "password" | base64decode}}'
# Get the visual dashboard web route
oc -n stackrox get route central -o jsonpath='{.spec.host}'

Log into the browser UI using the username admin and the password you extracted above.

Phase 2: Generating the Secure Initialization Bundle

Before any secured “Spoke” cluster can communicate with your new Central Hub, it needs cryptographic authentication keys.

Instead of configuring these manually, use the roxctl CLI utility or the Central UI to generate an Init Bundle:

  1. Inside the ACS UI Dashboard, navigate to Platform Configuration -> Integrations.
  2. Scroll down to Cluster Init Bundles and click Generate Bundle.
  3. Name your bundle (e.g., production-spokes-bundle) and download the generated Kubernetes secrets YAML file (cluster-init-bundle.yaml).

Apply this downloaded secret bundle directly to the namespace of every single Kubernetes cluster you wish to protect:

Bash

oc apply -f cluster-init-bundle.yaml -n stackrox

Phase 3: Deploying Secured Cluster Services (The Spokes)

Now that the init bundle secret is present on your target cluster(s), install the Advanced Cluster Security Operator on that spoke cluster just as you did in Phase 1.

Next, deploy the SecuredCluster custom resource to activate the sensors, collectors, and admission webhooks:

YAML

apiVersion: platform.stackrox.io/v1alpha1
kind: SecuredCluster
metadata:
name: production-spoke-cluster
namespace: stackrox
spec:
# The web endpoint address of your Central Hub (from Phase 1)
centralEndpoint: "central.stackrox.apps.hub-cluster.mycompany.com:443"
clusterName: "Production-US-East"
admissionControl:
listenOnCreates: true
listenOnUpdates: true
bypassOnTimeout: false # Fail closed for strict zero-trust security
perNodeCollection:
tuner:
type: BPF-CO-RE # Uses high-performance eBPF technology for runtime tracking

Phase 4: Production GitOps Architecture (Scaling with Helm)

If you are using ArgoCD or Flux to manage your fleet, you should deploy the Spoke cluster services using Helm rather than raw operator clicks.

Add the official Red Hat Helm repository to your GitOps manifest directory:

helm repo add redhat-cop https://redhat-cop.github.io/helm-charts
GitOps Helm Values File (secured-cluster-values.yaml)

Pass your custom infrastructure details directly to the Helm release engine:

YAML

clusterName: "Production-EU-West"
centralEndpoint: "central.stackrox.apps.hub-cluster.mycompany.com:443"
# Automatically pulls the authentication keys from the init bundle secret you applied
clusterInitBundleSecretRef: "production-spokes-bundle"
admissionControl:
enabled: true
enforceOnCreate: true
imagePullSecrets:
allowInsecure: false

Phase 5: Day-2 Operational Validation

Once both pieces are connected, verify your deployment topology is active by running:

# Verify the runtime sensors are active on every worker node
oc get daemonset collector -n stackrox

Go back to your Central Hub web browser portal and navigate to the Network Graph panel. You will instantly see your microservices charted visually in real-time, mapping live traffic and identifying immediately where your system lacks defensive Kubernetes network policy guardrails.

Leave a Reply