Expose selectable Coroot UI through the SSO boundary #92

🤖 Generated by the Daily AI Engineer (Codex instance)

Summary

Expose the selectable Coroot profiles at observability.${domain} through the
template's existing oauth2-proxy boundary. The explicit Coroot profiles already
render and validate, but they have no supported Gateway route for an operator to
open and evaluate the UI.

Part of #65 and #24.

Motivation and evidence

Current main renders no HTTPRoute in the observability namespace for either
clusters/local-coroot or clusters/prod-coroot. It also renders no Coroot entry
in the auth-proxy configuration, no cross-namespace ReferenceGrant, and no
auth-proxy-to-Coroot network path. Coroot Community Edition has no native OIDC,
so exposing it directly or enabling anonymous Admin without a complete SSO gate
would weaken the scaffold's security posture.

The affected audience is an operator who opts into Coroot and needs a supported,
authenticated way to evaluate its UI. The hypothesis is that coupling the route,
proxy, grant, and network path in one profile-only slice makes the option usable
without changing any default scaffold or exposing Coroot directly.

Proposed solution

• Add an observability.${domain} HTTPRoute to both explicit Coroot profiles.
  Its only backend is the existing oauth2-proxy service.
• Replace the retired OpenCost auth-proxy slot with a Coroot router and service
  that forwards to coroot-coroot.observability.svc.cluster.local:8080.
• Add the exact cross-namespace ReferenceGrant and least-privilege Cilium
  ingress/egress legs needed for that path.
• Enable Coroot's anonymous Admin role only in the explicit Coroot profiles and
  only when the complete oauth2-proxy boundary is present.
• Document the URL, the Community Edition SSO boundary, and how to opt out by
  returning to the default profile.

Acceptance criteria

• clusters/local-coroot and clusters/prod-coroot each render exactly one
  Coroot route at observability.${domain} with HSTS and generic Homepage
  metadata.
• The Gateway backend targets only oauth2-proxy; no route targets Coroot
  directly.
• Each opt-in render contains exactly one Coroot auth-proxy router/service,
  one matching ReferenceGrant, and matching least-privilege Cilium paths.
• The Coroot custom resource grants anonymous Admin only when every SSO gate
  element is present; validation fails for a direct route, a missing gate
  leg, or an uncoupled Admin role.
• OpenCost route, proxy, grant, and network references remain absent from the
  explicit Coroot profiles.
• Default clusters, default provider payloads, ksail.yaml, and
  ksail.prod.yaml remain byte-for-byte unchanged.
• Docker remains free of the Hetzner-only audit forwarder; Hetzner retains
  exactly one.
• The observability-option guard, both KSail workload validations, naming
  validation, and CI scaffold test pass.

Success signal and guardrail

The delivery signal is a complete rendered SSO path from Gateway to Coroot in
both opt-in profiles, exercised through the documented URL. The guardrail is zero
change to every default render and zero unauthenticated Gateway path to Coroot.

Alternatives considered

• A direct Gateway backend to Coroot was rejected because it bypasses SSO.
• Enabling anonymous Admin in the reusable Coroot base was rejected because the
  role would no longer be structurally coupled to the authentication boundary.
• Switching the root KSail defaults now was rejected because legacy log and
  metrics resources still need separate retirement slices.

Rough size

M