Registry builder (the leader's core) #3

New issue

Closed

opened 2026-09-13 20:39:58 +00:00 by ginjiruu · 0 comments

ginjiruu commented

2026-09-13 20:39:58 +00:00

Owner

Parent

Spec: Shared in-memory state model (Registry + Snapshot) — #1

What to build

On any change to any of the three CRDs, the leader lists all OauthClient/OidcPolicy/TokenExchangePolicy cluster-wide, structurally validates them, resolves each valid App, and writes the managed Registry Secret with the full nested per-App entry; it sets each App's CRD Available/Degraded status and observedGeneration. A structurally-invalid App is excluded from the Registry and marked Degraded. The three existing per-kind reconcilers become thin triggers into one idempotent, cluster-wide builder.

Acceptance criteria

On any change to any of the three CRDs, the builder lists all three kinds cluster-wide and rebuilds the Registry (idempotent).
A valid App produces the full nested per-App entry: identity (namespace, clientID, hostnames), shared (tokenEndpoint, jwks, secretRef, secretReady), and per-flow sections (OIDC: authorizationEndpoint, callbackURLs, policy config; Exchange: clientRef, scopes, subject-token source).
Structural validation excludes an App whose hostnames overlap another's, whose policy clientRef does not resolve, or whose clientSecretRef is malformed; the excluded App's CRD is marked Degraded.
CRD status Available/Degraded and observedGeneration are set for each App.
Verified in envtest: valid Client + policy + stubbed IdP → Registry holds the resolved App; hostname-collision or dangling clientRef → that App excluded + Degraded.

Blocked by

#2 — IdP resolve (discovery + JWKS, keep-last-good)

## Parent Spec: Shared in-memory state model (Registry + Snapshot) — https://git.animeteamspeak.moe/lab/authz-bridge/issues/1 ## What to build On any change to any of the three CRDs, the leader lists all `OauthClient`/`OidcPolicy`/`TokenExchangePolicy` cluster-wide, structurally validates them, resolves each valid App, and writes the managed Registry Secret with the full nested per-App entry; it sets each App's CRD `Available`/`Degraded` status and `observedGeneration`. A structurally-invalid App is excluded from the Registry and marked Degraded. The three existing per-kind reconcilers become thin triggers into one idempotent, cluster-wide builder. ## Acceptance criteria - [ ] On any change to any of the three CRDs, the builder lists all three kinds cluster-wide and rebuilds the Registry (idempotent). - [ ] A valid App produces the full nested per-App entry: identity (namespace, clientID, hostnames), shared (tokenEndpoint, jwks, secretRef, secretReady), and per-flow sections (OIDC: authorizationEndpoint, callbackURLs, policy config; Exchange: clientRef, scopes, subject-token source). - [ ] Structural validation excludes an App whose hostnames overlap another's, whose policy `clientRef` does not resolve, or whose `clientSecretRef` is malformed; the excluded App's CRD is marked Degraded. - [ ] CRD status `Available`/`Degraded` and `observedGeneration` are set for each App. - [ ] Verified in envtest: valid Client + policy + stubbed IdP → Registry holds the resolved App; hostname-collision or dangling `clientRef` → that App excluded + Degraded. ## Blocked by - #2 — IdP resolve (discovery + JWKS, keep-last-good)

ginjiruu added the

ready-for-agent

label

2026-09-13 20:40:29 +00:00

ginjiruu referenced this issue

2026-09-13 20:41:05 +00:00

Replica mirror (the local Snapshot) #4

ginjiruu referenced this issue

2026-09-13 20:41:06 +00:00

Leader freshness (runtime-secret tracking + JWKS refresh) #5

ginjiruu referenced this issue from a pull request that will close it,

2026-09-14 01:37:40 +00:00