QA Use Cases — ACS (Red Hat Advanced Cluster Security / StackRox)
Tool page: tools/stackrox.md. The owner
calls this platform ACS; the software is StackRox 4.11.6
(the open-source line of RHACS), run from the public operator
chart. Central lives on pro; the mini’s Argo CD drives pro
as an external cluster — pro has no Argo of its own
(source: stackrox.md). Front door: acs.rhels.com.
Acceptance probe: scripts/check-pro-stackrox.sh.
Admin stories
ACS-A1 — Central acceptance probe [CLI]
- Persona: Platform admin.
- Steps: run
scripts/check-pro-stackrox.shon the mini. - Expected: all 5 stages OK — cluster Secret, Argo apps, token authentication, Central and Sensor deployments (source: stackrox.md Part B).
- Assert: script exit code
0(it already exits non-zero on any stage FAIL — this story is the suite adopting it verbatim).
ACS-A2 — Secured-cluster census [config/API]
- Persona: Platform admin. Goal: every enrolled cluster reports HEALTHY in Central, and only enrolled clusters appear.
- Steps: query Central’s cluster list (API with a scoped token, or the UI census).
- Expected:
proHEALTHY (its own SecuredCluster) and the mini cluster HEALTHY (enrolled 2026-10-28; init bundle in Vault); CRC absent — staged, not live (ACS-A3) (source: stackrox.md status; lab record — mini enrollment PR #57). - Assert:
GET /v1/clusters→ entries for pro and mini withhealthStatus.sensorHealthStatus == "HEALTHY"; no entry with namecrc(until ACS-A3’s proof replaces this expectation at CRC start).
ACS-A3 — CRC enrollment staged and pending (pending-state) [config/API]
- Persona: Platform admin. Goal: everything needed to enroll CRC exists before CRC starts. This expectation is a pending-state, not a TBD.
- Steps: confirm CRC’s init bundle exists in Vault (metadata only); confirm the sync script and secured-cluster GitOps are in the repos; confirm Central shows no CRC cluster (ACS-A2).
- Expected: bundle present, sync path ready, cluster
absent. At CRC’s next start this story is replaced by the
proof: run
sync-crc-init-bundle.sh, Sensor connects, clustercrcreports HEALTHY in Central (source: CRC-start checklist, “StackRox — CRC as a secured cluster”). - Assert:
GET /v1/secret/metadata/platform/stackrox/crc-init-bundle→200; the sync script exists in the gitops repo; ACS-A2’s no-crcassertion holds.
ACS-A4 — Platform configuration baseline [config/API]
- Persona: Platform admin (break-glass local admin).
- Steps: with the local admin (credential via the Service Directory), list Central’s policies and scanner configuration.
- Expected: the default policy set present and enabled; Scanner V4 active, legacy scanner disabled (per the Central CR) (source: stackrox.md — Central CR shape).
- Assert:
GET /v1/policies→ count >= the shipped default set size and every default policydisabled == false;GET /v1/scanner/definitions-equivalent reports the V4 indexer/matcher reachable. The default-set size is a manifest value the suite records at first run — a name-by-name baseline is TBD (see Gaps).
ACS-A5 — API token posture [config/API]
- Persona: Platform admin.
- Steps: list Central’s API tokens and roles.
- Expected: tokens are few, named, role-scoped. Assert around the known caveat: StackRox 4.11.6’s REST token-revoke returns 501, so the six inert bundle-generation tokens from the enrollments await UI cleanup — recorded finding, not a new failure (source: lab record, 2026-10-28/29).
- Assert: every token has a non-empty name and a role; token count == previous run’s count (any change is a diff event, not a silent pass).
User stories
ACS-U1 — Admin via directory SSO [browser]
- Persona: the owner’s directory account (in
acs-admins). - Steps: open
acs.rhels.com, sign in with “Lab LDAP (Dex OIDC)”. - Expected: session lands with the Admin role — the
recorded rule is
acs-admins→ Admin, proven end-to-end for this account (source: stackrox.md, “LDAP SSO”). - Assert:
GET /v1/auth/status(or the UI role badge) → resource access contains Admin-level permissions; the Dex groups claim containsacs-admins.
ACS-U2 — Directory user with no group gets no access (negative) [browser]
- Persona:
dev2. - Steps: sign in via Dex with dev2’s credentials.
- Expected: dev2 authenticates at Dex; Central grants no access — “everyone else in the directory → no access” (source: stackrox.md, SSO rules).
- Assert: Central’s auth status for dev2 → no resource roles granted (empty access set); any granted role is a critical failure, reported as such.
ACS-U3 — Break-glass stays break-glass [browser]
- Persona: Platform admin.
- Steps: sign in with the local
adminaccount. - Expected: login succeeds — and the story passes only if ACS-U1 also passes: break-glass is a fallback, never the primary (source: stackrox.md Part B).
- Assert: local login →
200session; suite-level rule:ACS-U3.status == PASSrequiresACS-U1.status == PASS.
ACS-U4 — Vulnerability lookup for my own namespaces (TBD) [config/API]
- Persona:
dev1. Goal: “what CVEs are in the images running in my BSN’s namespaces?” — answered as a per-image rollup stamped with scan time and source. - Expected: TBD — the tool does not exist yet. This is the security-MCP v1 story (lab-monorepo #43: BSN → namespaces → pods/images → CVE rollup, StackRox as the source, server-side dev-support authorization); the scan pipeline (#44) and new-image auto-scan (#45) are phase 2. Written now so the MCP’s acceptance inherits it, including the negative half: a BSN outside the caller’s dev-support group returns a denial with no data (source: lab record — owner decision 2026-10-28).
- Assert: not yet expressible — the MCP tool contract
is the missing piece; when #43 lands, this story gains:
tool result for own BSN contains per-image CVE entries with
scanned_at+source == "stackrox"; foreign BSN → denial, zero image records. Flagged manual-only until #43 in Gaps.
Gaps
- Doc drift: stackrox.md lists “no Kyverno on pro” as posture debt — stale since 2026-10-29 (the request-floor twin landed; see kyverno.md). Image-signature verification on pro remains genuinely absent.
- TBD: no name-by-name baseline for Central’s policies (ACS-A4) or a sanctioned token inventory beyond count-and-roles (ACS-A5).
- Known seam: Central’s OIDC provider lives in Central’s database, not git (script re-applies it) (stackrox.md) — after a Central rebuild, ACS-U1 is expected to fail until the script runs; the suite should report that state as the known seam, not a mystery.
- Manual-only: ACS-U4 only, and only until the security MCP (#43) exists.