coulomb/key-cape
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add keycape check-config; reject duplicate clientIds
All checks were successful
Authentication acceptance / acceptance (push) Successful in 1m25s
Details
Authentication acceptance / provider-contract (push) Successful in 25s
Details
Build and Publish Container Image / build-and-push (push) Successful in 43s
Details

Browse source 
net-kingdom asked for a way to validate a rendered configuration before
keycape-client.py restarts KeyCape (oidc-browser-relying-party review R4).
check-config runs every startup check that needs no secret, key or upstream:
validation, registry build, global tokenLifetime, policy-store clients and,
with --env-names, the secretRef bindings. The report carries no values.

ValidateConfig now refuses a clientId registered twice. The registry is a
map, so a duplicate silently replaced the earlier registration.

Also records the owners' amended CCR-2026-0018 sequence in KEY-WP-0013.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 779409@bnt-lap001
Assistant-Session: c658ca06-19b5-468d-be64-2985dc20bfd3
This commit is contained in:
tegwick 2026-10-10 13:28:36 +02:00
parent 5bc4a366b0
commit c528daa5be
9 changed files with 267 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

13
workplans/KEY-WP-0013-approval-engine-resource-audience.md
View file

@ -558,3 +558,16 @@ railiance-platform asked for on 2026-09-15, to railiance-platform, approval-engi
and net-kingdom: remove the registration (attended), verify `invalid_client`,
unbind the env, retire the ESO delivery, then retire custody. The proposal executes
nothing. Each owner confirms their step and the founder schedules the attended window.
**2026-10-10, amended by the owners.** net-kingdom: step 1 (`keycape-client.py
apply --operation remove`, case acceptance CCR-2026-0018) only patches
`sso/keycape-config` and does not restart. The step-3 env removal triggers the one
rollout, and the new pod starts with neither the client nor the env. Step 2's
`invalid_client` check follows that rollout. Rollback runs in reverse: env first,
then the client. railiance-platform (RPF-WP-0035-T10): step 4 also retires the
ClusterSecretStore, the Kubernetes-auth role and the reader policies, through an
attended prune sync run strictly after step 3. Step 5 is a metadata delete, not an
archive, run only after the step-2 receipt. Steps 1-5 can share one attended
window. Still open: approval-engine's reconfirmation that there is no presenter,
and the founder scheduling the window. Before that rollout, run
`keycape check-config` on the patched configuration.