key-cape/docs/approval-clients-rollout.md

Approval service clients: prepared rollout

KEY-WP-0013-T02/T06, 2026-09-08. Prepared candidate; not deployed.

The implementation and verification correction are published at dcebd46. Forgejo's image is main-dcebd46, with immutable manifest digest sha256:7ff54c54e63ee172ae9e6e7fd2da96e427352f712343d74626ee6fe0f6f82611. The complete Go suite and go vet ./... passed. The registry image was pulled by digest and its /keycape verify-client --help command enumerated the expected verification options (the Go flag help path exits 1). The verifier is a keycape subcommand, not a separate /verify-client executable. No live credential was used in these checks.

Negative evidence now requires the exact token endpoint, issuer error and feature: scope rejection is HTTP 400 / invalid_profile_usage / scope; predecessor rejection is HTTP 401 / invalid_profile_usage / Authorization. A timeout, server error, invalid token, JWKS failure or unrelated refusal fails verification. Provider response bodies and tokens are never printed.

Admission inputs

1. Platform CCR-2026-0017 and CCR-2026-0018 remain proposed. Their named platform-operator and key-cape-owner reviews precede any activation. provisioning request records the exact paths, CLIENT_SECRET field and Kubernetes/env mappings.
2. NetKingdom must observe and verify the actual signed upstream ID token from the existing human flow, recording only the issuer claim and proof metadata. Pin that exact value in authelia.issuer through the configuration owner's contained path. Public discovery currently advertises https://auth.coulomb.social; discovery alone does not satisfy this gate. Preserve the existing signing key and client registrations. Prove an existing human login before and after cutover; this image also includes stricter authorization-code redirect and grant binding.
3. The platform-owned attended first-provision command uses only warden access openbao-platform-admin-login --exec -- <reviewed-command> with its unique metadata-only receipt. It must follow the two CCRs and the platform rollout document. Do not execute the child directly. The unrelated interim credential proxy's explicit policy 403 remains WARDEN-WP-0039-T03; an outage fallback is not permission to get credentials for this rollout.

Prepared deployment change

approval-clients-deployment.patch.yaml is a strategic merge patch for sso/keycape, whose deployment source remains net-kingdom/sso-mfa/k8s/keycape/deployment.yaml. Transfer the reviewed changes into that owning source at the admitted cutover; this file is a preparation, not a second deployment authority.

It pins the image, adds the two exact Secret references and uses /readyz for traffic readiness while retaining /healthz for liveness. Recreate ensures one issuer instance during replacement: operations.md states that login sessions and authorization codes are process-local. The old manifest's default rolling surge can briefly create two instances. Expect a short login interruption and loss of in-flight login sessions during replacement.

Apply the platform policies/roles, CAS=0 initial custody, two stores and two ExternalSecrets in their owner-prescribed order; require Valid/SecretSynced before deploying the reading image and updated client config together. Do not pre-create ESO-owned Secrets. A dry-run of this patch proves API acceptance of the object shape only; it cannot prove the referenced Secrets or configuration.

Acceptance and rollback

Run the two verify-client commands from the provisioning request through the admitted protected delivery. In addition to the tool's checked signature, issuer, audience, subject, tenant, scopes and required roles, record independent verification of the exact role set and exp - iat = 900: the tool's expect-roles checks inclusion and does not itself establish the 15-minute lifetime. Initial provisioning has no real predecessor to revoke; test a wrong secret and retain predecessor rejection for an actual subsequent rotation. Retain expiry/revocation and excessive-scope evidence, and platform cross-path, wrong-service-account, outside-namespace and parent-listing denials.

Before mutation the deployment/configuration owner retains the previous image, configuration revision and Secret metadata through its protected recovery path. On failed readiness or existing-human-login regression, restore that compatible configuration/image pair (main-153258b is the observed prior image), then follow the platform document's ExternalSecret/policy rollback. An image-only revert does not restore the changed client configuration. Keep custody versions until registrations are explicitly disabled; never destroy as incidental cleanup.

These CCRs supply verifier-side copies only. Client-side read lanes, the approval audit sender credential and live claim/consume proof remain open in RPF-WP-0035-T05, AUDIT-WP-0009-T09, APPROVAL-WP-0002 and GLAS-WP-0015's existing coordination chain. The human UI's real callback and MFA proof remain KEY-WP-0013-T05; they do not block these independent service registrations.