Kiali OpenID: investigate per-user RBAC (currently disable_rbac, whole-mesh read-only for all realm users)

[ausbru87]

Summary

Kiali is now fronted by Keycloak OpenID SSO (PR #31) with auth.openid.disable_rbac: true and deployment.view_only_mode: true. As a result, every authenticated coder-realm user gets the same read-only view of the entire mesh. There is no per-user or per-namespace access control. We should investigate enabling real per-user RBAC.

Why it is this way today

Kiali's openid strategy can enforce per-user Kubernetes RBAC only when the cluster API server itself trusts the same OIDC issuer, so it accepts the user's Keycloak token for SelfSubjectAccessReview / namespace listing. This GovCloud EKS API server is not integrated with Keycloak as an OIDC token issuer, so per-user RBAC is unavailable and disable_rbac: true is the supported setting for that case. view_only_mode: true keeps the shared access read-only so no user can mutate mesh config from Kiali.

This is acceptable for the demo (any authenticated viewer, nobody can change config), but it is a limitation to revisit for a hardened/multi-tenant setup.

Options to investigate

1. Integrate the EKS API server with Keycloak OIDC via aws eks associate-identity-provider-config (issuer https://auth.usgov.coderdemo.io/realms/coder, client kiali or a dedicated cluster client). Then set auth.openid.disable_rbac: false, align username_claim with the cluster --oidc-username-claim, and bind Keycloak users/groups to Kiali RBAC via RoleBinding/ClusterRoleBinding against the kiali ClusterRole. Confirm GovCloud EKS supports OIDC IdP association.
2. kube-oidc-proxy (or similar) in front of the API, using Kiali's auth.openid.api_proxy / api_proxy_ca_data. Useful if direct EKS OIDC association is not viable.
3. Group-gated login. Note: Kiali does not natively restrict login to a specific group without RBAC (kiali/kiali discussion #6600). Any group gating would need RBAC (option 1/2) or an external policy at the gateway (e.g. an Istio AuthorizationPolicy / external authz checking the groups claim) layered in front.

Scope / pointers

• Config: deploy/istio/observability/kiali-server-values.yaml, deploy/istio/observability/kiali.yaml.
• Keycloak client + secret: scripts/setup-kiali-oidc.py, deploy/istio/observability/externalsecret-kiali-oauth.yaml. The groups claim is already emitted by the kiali client, so it is available for group-based policy.
• Background and rationale: the "Auth" section of deploy/istio/observability/README.md.

Acceptance idea

Decide and document whether per-user/namespace-scoped Kiali access is required for this environment; if so, implement option 1 (preferred) and flip disable_rbac to false with at least one user and one group RBAC binding verified.

---

Filed by Coder Agents on behalf of @ausbru87. Follow-up to PR #31.