viktor/infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(k8s-dashboard): drop group-restriction policy; RBAC is the gate

Browse source 
The Authentik group policy denied admins: it gated on kubernetes-* group
membership, but cluster access is email-based RBAC (User bindings from
k8s_users), not group-based. vbarzin@gmail.com (Home Server Admins) gets
cluster-admin via oidc-admin-vbarzin but isn't in any kubernetes-* group,
so the gate locked him out. Apiserver RBAC is now the sole gate — matching
the kubelogin CLI (authenticate freely, RBAC decides actions).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Viktor Barzin 2026-06-04 03:08:44 +00:00
parent ad3432d685
commit e436af8d8c
1 changed files with 9 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

26
stacks/k8s-dashboard/authentik.tf
View file

@ -89,20 +89,12 @@ resource "authentik_application" "k8s_dashboard" {
policy_engine_mode = "any"
}
# Restrict who can complete the OIDC flow to the K8s RBAC groups.
resource "authentik_policy_expression" "k8s_dashboard_groups" {
name = "k8s-dashboard-group-access"
expression = <<-EOT
return (
ak_is_group_member(request.user, name="kubernetes-admins")
or ak_is_group_member(request.user, name="kubernetes-power-users")
or ak_is_group_member(request.user, name="kubernetes-namespace-owners")
)
EOT
}
resource "authentik_policy_binding" "k8s_dashboard_groups" {
target = authentik_application.k8s_dashboard.uuid
policy = authentik_policy_expression.k8s_dashboard_groups.id
order = 0
}
# NO group-restriction policy: the kube-apiserver RBAC (per-user `User`
# bindings keyed on the OIDC email claim, from k8s_users in stacks/rbac) is the
# real, authoritative gate — exactly like the kubelogin CLI. Any Authentik user
# can complete the login, but only users with an RBAC binding can do anything
# (everyone else sees an empty/forbidden dashboard). A group gate here was
# both redundant with RBAC AND wrong: it gated on `kubernetes-*` group
# membership, but admins (e.g. vbarzin@gmail.com, in Home Server Admins) get
# cluster-admin via their email binding, not via those groups — so the gate
# locked out legitimate admins.