docs: close live approval service registration gate
Assistant: codex Assistant-Model: gpt-5.6-luna Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
This commit is contained in:
parent
cf23469ead
commit
3a4fd38c00
3 changed files with 275 additions and 83 deletions
|
|
@ -1,89 +1,42 @@
|
|||
# Approval service clients: prepared rollout
|
||||
# Approval service clients: live rollout accepted
|
||||
|
||||
`KEY-WP-0013-T02/T06`, 2026-09-08. Prepared candidate; **not deployed**.
|
||||
KEY-WP-0013-T02 is complete on 2026-09-09. Both verifier-side credential requests,
|
||||
CCR-2026-0017 and CCR-2026-0018, have explicit user approval as platform operator
|
||||
and KeyCape owner and are now verified. [Live receipt](evidence/2026-09-09-keycape-verifier-admission.json).
|
||||
|
||||
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.
|
||||
Both clients run on one ready KeyCape replica using the immutable image
|
||||
`forgejo.coulomb.social/coulomb/key-cape@sha256:7ff54c54e63ee172ae9e6e7fd2da96e427352f712343d74626ee6fe0f6f82611`.
|
||||
NetKingdom owns the deployed manifest, `Recreate` strategy, `/readyz` readiness,
|
||||
and exact client registrations. Both ESO-owned Secrets are synchronized from
|
||||
OpenBao version 1. The signing key and unrelated configuration bytes are preserved.
|
||||
|
||||
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.
|
||||
Both clients passed the native verifier from that pinned image and independent
|
||||
RS256/JWKS verification with exact issuer, audience, subject, tenant, roles,
|
||||
scopes and a 900-second lifetime. Wrong secrets and excess scopes were refused;
|
||||
the human OpenBao client was refused `approval:consume`. Existing human OpenBao
|
||||
login passed before and after cutover, with attended sessions self-revoked.
|
||||
|
||||
## Admission inputs
|
||||
The deployment owner exercised compatible rollback and version-preserving
|
||||
resume. Its executable procedure and reproducible synthetic HTTPS exercise live
|
||||
in `net-kingdom:sso-mfa/k8s/keycape/`, documented in
|
||||
`net-kingdom:docs/keycape-approval-clients-rollout.md`. The verifier runs inside
|
||||
the existing attended owner process; credentials stay in memory and a child
|
||||
environment. The pod's internal-only egress policy remains unchanged.
|
||||
|
||||
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](approval-engine-provisioning-request.yaml) records the
|
||||
exact paths, `CLIENT_SECRET` field and Kubernetes/env mappings.
|
||||
2. The actual signed upstream issuer is now proved as
|
||||
**`https://auth.coulomb.social`** by the admitted one-shot probe on 2026-09-08
|
||||
at 21:44:44 UTC. Signature, audience, validity window and nonce passed; the
|
||||
Job exited 0 and every temporary resource was removed. See
|
||||
[the live receipt](evidence/2026-09-08-upstream-issuer-live-proof.json).
|
||||
NetKingdom pinned that exact value in `authelia.issuer` on 2026-09-09
|
||||
through its exercised issuer-only helper; Secret revision `58713343`.
|
||||
[Pin receipt](evidence/2026-09-09-upstream-issuer-pin.json) proves all other
|
||||
config bytes and Secret data unchanged. The running Deployment was unchanged. Prove an existing
|
||||
human login before and after cutover; the probe established upstream identity
|
||||
only, while this image also changes 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.
|
||||
Containerd readiness matches the manifest in `imageID`. Independent JWT checks
|
||||
use the native contract's 30-second future-iat bound while retaining strict
|
||||
not-before and expiry. Natural JWT expiry and actual predecessor rotation were
|
||||
not exercised by this initial provision and remain required for their relevant
|
||||
subsequent owner acceptance.
|
||||
|
||||
## Prepared deployment change
|
||||
The original [candidate patch](approval-clients-deployment.patch.yaml) remains a
|
||||
preparation reference; NetKingdom's manifest is deployment authority. Candidate
|
||||
Go tests and vet passed previously; this window added eight real local OpenBao
|
||||
checks, ten configuration/recovery/clock checks, 53 credential-change regressions,
|
||||
and a complete pinned-image HTTPS/native-verifier exercise with synthetic keys.
|
||||
|
||||
[approval-clients-deployment.patch.yaml](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](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.
|
||||
KEY-WP-0013-T05 retains the real approval UI callback and MFA/PKCE proof.
|
||||
RPF-WP-0035-T05 retains separate client-side credential delivery; AUDIT-WP-0009-T09
|
||||
retains audit custody. APPROVAL-WP-0002 and SECRETS-WP-0009-T03 retain deployed
|
||||
claim/consume, expiry/revocation and native credential delivery. These verifier
|
||||
copies do not grant client retrieval or factory execution/spending.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue