design-proposals: Keycloak SSO for tenant Grafana#15
Conversation
Proposes that the monitoring chart auto-renders a per-tenant KeycloakClient + secret + Grafana auth.generic_oauth block for every non-root tenant, mirroring how cozy-dashboard already gets per-tenant SSO wiring. Default behaviour for tenant-root stays identical. Replaces the production workaround currently in use on the TTK platform (manual KeycloakClient patches + monitoring-system HelmRelease suspend + kubectl patch grafana), which is brittle and freezes all chart updates for the affected tenant. Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
|
Warning Review limit reached
More reviews will be available in 55 minutes and 44 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a design proposal for implementing automatic Keycloak SSO for tenant Grafana instances in Cozystack. The proposal details the resource architecture, secret mirroring, and role mapping configurations. Feedback on the proposal highlights two key points: first, Grafana's native syntax for environment variable interpolation should be corrected to $__env{GF_OAUTH_CLIENT_SECRET}; second, using ExternalSecret (ESO) is recommended over Reflector for secret mirroring, as Reflector requires annotations on the operator-managed source secret which may not be supported.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| enabled: "true" | ||
| name: Keycloak | ||
| client_id: grafana-{{ .Release.Namespace }} | ||
| client_secret: ${GF_OAUTH_CLIENT_SECRET} |
There was a problem hiding this comment.
Grafana's native syntax for environment variable interpolation in configuration files is $__env{VAR_NAME} rather than ${VAR_NAME}. Using $__env{GF_OAUTH_CLIENT_SECRET} is recommended to ensure the configuration is parsed correctly by Grafana.
| client_secret: ${GF_OAUTH_CLIENT_SECRET} | |
| client_secret: $__env{GF_OAUTH_CLIENT_SECRET} |
|
|
||
| Two ways to wire this: | ||
|
|
||
| - **Option A (proposed): operator-managed in `cozy-keycloak`, projected via existing `External Secrets / Reflector`.** Cozystack already runs `external-secrets-operator` for similar cross-namespace secret plumbing. The chart renders an `ExternalSecret` (or equivalent `Reflector`-annotated mirror) so the tenant ns gets a copy automatically. No human action. |
There was a problem hiding this comment.
When using Reflector for secret mirroring, the source secret in cozy-keycloak must be annotated with reflector.v1.k8s.io/reflection-allowed: "true". Since this secret is managed and generated by the Keycloak operator, adding these annotations might not be supported directly. Using ExternalSecret (ESO) is a more robust approach as it does not require modifying the source secret.
1 participant
Summary
Adds a draft design proposal for making Keycloak SSO automatic on every tenant Grafana, not just the root tenant's. Today the monitoring chart hardcodes the OAuth wiring against
_cluster.\"root-host\", so child tenants ship withoutauth.generic_oauthconfigured at all — operators end up with only the local admin/password login.The proposal mirrors how
cozy-dashboardalready wires per-tenantKeycloakClient+Secret+ dashboard config. Per non-root tenant the monitoring chart renders:KeycloakClient grafana-<tenant>-clientincozy-keycloakscoped to that tenant's host;Secret(mirrored to the tenant ns via ESO / Reflector — picked one of two options in the body, open question for reviewers);auth.generic_oauthblock +GF_OAUTH_CLIENT_SECRETenv on theGrafanaCR.Default role mapping mirrors today's root behaviour (
cozystack-cluster-admin→ Admin), but is overridable per tenant for tenant-scoped groups.Why now
The TTK platform operations team is running a manual workaround in production: patch the shared
grafana-clientKeycloakClientto add child redirect URIs, mirror theSecretby hand,suspend: truethe tenant's monitoringHelmRelease, andkubectl patch grafana ...to add the OAuth block. This freezes all monitoring chart updates for the affected tenant and is brittle (collisions with Grafana operator reconciles caused multi-RS rollout loops in our deployment). The fix belongs in-chart.Open questions for reviewers
In the body — copied here so they don't get lost:
allowedGroupsvalue for non-root tenants:cozystack-cluster-admin(today's root behaviour, convenient) or empty (safer, but worse first-day UX)?KeycloakRealmGroups (grafana-tenant-X-admin/viewer) or leave it to the operator?ExternalSecret, Reflector annotation, or chart-managed dual-write?IdentityProviderabstraction reusable for Argo CD / JupyterHub / etc.) now, or wait until a second use-case forces the abstraction?