project isolation testing

[gsanseverino]

Summary

Two paired artifacts that document and exercise the four layers k8tre relies on to keep one Project's resources out of reach of another Project's users.

tests/test-project-isolation.sh

Idempotent end-to-end check. Creates two Projects (alpha, bravo) + Groups + Users (alice, bob), then asserts:

• Keycloak password-grant works and the JWT carries aud=backend.
• /auth/validate returns 200 for the user's own project and 403 for the other, symmetrically for both users (the real authz gate — layer 2).
• The default ServiceAccount in project-alpha cannot list/create/delete pods or secrets in project-bravo (layer 3, RBAC).
• A pod in project-alpha cannot TCP-reach a pod in project-bravo (layer 4, Cilium NetworkPolicy).
• User CRs exist with the right group memberships.

Output uses three states: PASS / FAIL / WEAK. On a healthy cluster: 14 PASS, 0 FAIL, 2 WEAK (the two WEAK results are documented design gaps, not regressions).

docs/project-isolation.md

Walks through the four enforcement layers (UX /projects filtering, the /auth/validate gate, Kubernetes RBAC, Cilium NetworkPolicy), explains how to run the script, what it asserts and what it does not cover (token replay across authorized projects, spawner SA RBAC, intra-namespace traffic, control plane), the two known weak spots (logged-in users can still GET /projects/<other>/apps and /launch/<other>/<app> — metadata leak, no data leak; one-line fix in get_apps()/launch_app() noted), and the three Keycloak/network-policy quirks the script's setup phase has to work around (kcadm.sh defaults to temporary passwords; firstName/lastName are required for password-grant; pod-network blocks in-pod kubectl access to the API server).

Test plan

• StackIT dev cluster: script runs idempotently, returns 14 PASS, 0 FAIL, 2 WEAK on a steady-state cluster.

🤖 Generated with Claude Code