Restore cluster-internal-only Keycloak DCR (A1+trust)

Date: 2026-07-02 Status: Accepted Decision: hl-ll5p Deciders: Sean Brandt

Context

ADR hl-amad temporarily removed the Traefik network-level deny on Keycloak’s DCR endpoint because agentgateway’s own DCR proxy call hairpinned through the public route and got 403’d by that same deny, leaving anonymous DCR governed only by Keycloak’s loopback Trusted-Hosts policy. hl-amad’s own Consequences section explicitly flagged this as a temporary, accepted trade-off and deferred restoring the cluster-internal-only posture to bead hl-thsf.2. This decision closes that gap: it routes agentgateway’s DCR call directly in-cluster (via an already-merged CoreDNS rewrite, delivered by an unrelated bead, hl-rs8m) and gives the agentgateway pod TLS trust for Keycloak’s ICA1-issued certificate, so the network-level deny can be re-added without breaking the gateway’s own legitimate DCR call.

Decision

Re-add the Traefik network-level deny on the DCR path now that agentgateway’s DCR call is routed cluster-internally and trusts Keycloak’s ICA1 certificate, restoring network-level cluster-internal- only DCR. Keycloak’s app-level Trusted-Hosts policy is left unchanged (not tightened) — the network deny is the sole restored control.

Rationale

• Closes the exact gap hl-amad’s own Consequences section flagged as an accepted, temporary trade-off
• A network-level deny blocks LAN-direct DCR requests before they ever reach Keycloak, a materially stronger control than an app-level policy alone
• Now safe to re-add because agentgateway’s DCR call no longer hairpins through the public route it would otherwise 403 itself against

Alternatives Considered

• Keep the loopback-Trusted-Hosts-only posture (status quo, hl-amad) (rejected): no further work needed and Phase 1 DCR was already unblocked, but the DCR endpoint stays reachable at the network layer from the LAN — only an app-level Keycloak policy stands between an anonymous LAN caller and client registration
• Restore the network-level deny via CoreDNS-internal routing + ICA1 pod trust (A1+trust) (chosen): restores true network-layer cluster-internal-only DCR, matching the original hl-xktj intent, without regressing agentgateway’s own legitimate DCR call; cost is a maintained public-CA-bundle artifact and TLS-trust wiring dependency on the agentgateway pod
• Also re-enable Keycloak-side Trusted-Hosts host-match (rejected/deferred): would add app-level defense-in-depth on top of the network deny, but expands scope beyond the network fix — deferred as a separate, independently-decidable improvement

Consequences

• Positive: cluster-internal-only DCR restored at the network layer, matching the original hl-xktj intent
• Positive: agentgateway’s own DCR path verified unaffected via a live post-deploy validation gate
• Negative: agentgateway’s TLS trust now depends on a vendored, separately-maintained public CA bundle that must stay current
• Negative: depends on an external precondition (the CoreDNS rewrite) delivered by an unrelated bead (hl-rs8m)
• Neutral: Keycloak-side Trusted-Hosts host-match remains loopback-only/unchanged; re-enabling it is deferred as a separate possible follow-up