RHELS LAB
Contents · the agent book

Agent book · QA Use Cases

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.sh on 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: pro HEALTHY (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 with healthStatus.sensorHealthStatus == "HEALTHY"; no entry with name crc (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, cluster crc reports 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-crc assertion 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 policy disabled == 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 contains acs-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 admin account.
  • 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 → 200 session; suite-level rule: ACS-U3.status == PASS requires ACS-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.