cb96d5d590
The apiserver rejects the email username-claim when email_verified is false (invalid bearer token 401). Authentik external/social users are unverified, so the default scope-email mapping fails. Mirror the proven kubernetes provider: use the custom 'Kubernetes Email (verified)' mapping (hardcodes email_verified=true) + 'Kubernetes Groups'. Drop the now-unneeded dual-aud mapping (apiserver trusts the k8s-dashboard issuer w/ audience=client_id) and align oauth2-proxy scope to 'openid email profile groups'. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
115 lines
4.8 KiB
HCL
115 lines
4.8 KiB
HCL
# -----------------------------------------------------------------------------
|
|
# Authentik OIDC application for the Kubernetes Dashboard (via oauth2-proxy).
|
|
#
|
|
# Confidential client `k8s-dashboard`. A custom scope mapping emits
|
|
# aud = ["kubernetes","k8s-dashboard"] so BOTH the kube-apiserver
|
|
# (--oidc-client-id=kubernetes) and oauth2-proxy (client_id=k8s-dashboard)
|
|
# accept the id_token. The existing UI-managed `kubernetes` public client
|
|
# used by the kubelogin CLI is untouched.
|
|
#
|
|
# Provider token: Vault secret/authentik -> tf_api_token (same as
|
|
# stacks/authentik/authentik_provider.tf).
|
|
# -----------------------------------------------------------------------------
|
|
|
|
data "vault_kv_secret_v2" "authentik_tf" {
|
|
mount = "secret"
|
|
name = "authentik"
|
|
}
|
|
|
|
provider "authentik" {
|
|
url = "https://authentik.viktorbarzin.me"
|
|
token = data.vault_kv_secret_v2.authentik_tf.data["tf_api_token"]
|
|
}
|
|
|
|
data "vault_kv_secret_v2" "k8s_dashboard" {
|
|
mount = "secret"
|
|
name = "k8s-dashboard"
|
|
}
|
|
|
|
data "authentik_flow" "default_authorization_implicit_consent" {
|
|
slug = "default-provider-authorization-implicit-consent"
|
|
}
|
|
|
|
data "authentik_flow" "default_provider_invalidation" {
|
|
slug = "default-provider-invalidation-flow"
|
|
}
|
|
|
|
# RS256 signing keypair — REQUIRED, else Authentik signs the id_token with
|
|
# HS256 (client-secret HMAC) and publishes an EMPTY JWKS, so oauth2-proxy AND
|
|
# the apiserver fail signature verification ("failed to verify id token
|
|
# signature" / 500 on the OAuth callback). Same keypair the `kubernetes`
|
|
# provider uses.
|
|
data "authentik_certificate_key_pair" "signing" {
|
|
name = "authentik Self-signed Certificate"
|
|
}
|
|
|
|
# Scope mappings — MIRROR the proven `kubernetes` provider exactly. Two are
|
|
# custom (no `managed` field) and are looked up by name:
|
|
# * "Kubernetes Email (verified)" hardcodes `email_verified: true`. REQUIRED:
|
|
# the apiserver rejects the email username-claim when email_verified is
|
|
# false (Authentik external/social users are unverified), so the default
|
|
# `scope-email` mapping (which passes through the real false) yields
|
|
# "invalid bearer token" 401s. This custom mapping is why the CLI works.
|
|
# * "Kubernetes Groups" emits the `groups` claim (scope_name=groups), so the
|
|
# client must request the `groups` scope (see oauth2_proxy.tf).
|
|
# The token `aud` defaults to the client_id (`k8s-dashboard`), which the
|
|
# apiserver's k8s-dashboard issuer trusts — no custom audience mapping needed.
|
|
data "authentik_property_mapping_provider_scope" "openid" {
|
|
managed = "goauthentik.io/providers/oauth2/scope-openid"
|
|
}
|
|
data "authentik_property_mapping_provider_scope" "profile" {
|
|
managed = "goauthentik.io/providers/oauth2/scope-profile"
|
|
}
|
|
data "authentik_property_mapping_provider_scope" "email_verified" {
|
|
name = "Kubernetes Email (verified)"
|
|
}
|
|
data "authentik_property_mapping_provider_scope" "groups" {
|
|
name = "Kubernetes Groups"
|
|
}
|
|
|
|
resource "authentik_provider_oauth2" "k8s_dashboard" {
|
|
name = "k8s-dashboard"
|
|
client_id = data.vault_kv_secret_v2.k8s_dashboard.data["oauth2_proxy_client_id"]
|
|
client_secret = data.vault_kv_secret_v2.k8s_dashboard.data["oauth2_proxy_client_secret"]
|
|
client_type = "confidential"
|
|
|
|
authorization_flow = data.authentik_flow.default_authorization_implicit_consent.id
|
|
invalidation_flow = data.authentik_flow.default_provider_invalidation.id
|
|
|
|
allowed_redirect_uris = [
|
|
{
|
|
matching_mode = "strict"
|
|
url = "https://k8s.viktorbarzin.me/oauth2/callback"
|
|
},
|
|
]
|
|
|
|
access_token_validity = "hours=1"
|
|
refresh_token_validity = "days=30"
|
|
include_claims_in_id_token = true
|
|
signing_key = data.authentik_certificate_key_pair.signing.id
|
|
|
|
property_mappings = [
|
|
data.authentik_property_mapping_provider_scope.openid.id,
|
|
data.authentik_property_mapping_provider_scope.profile.id,
|
|
data.authentik_property_mapping_provider_scope.email_verified.id,
|
|
data.authentik_property_mapping_provider_scope.groups.id,
|
|
]
|
|
}
|
|
|
|
resource "authentik_application" "k8s_dashboard" {
|
|
name = "Kubernetes Dashboard"
|
|
slug = "k8s-dashboard"
|
|
protocol_provider = authentik_provider_oauth2.k8s_dashboard.id
|
|
meta_launch_url = "https://k8s.viktorbarzin.me"
|
|
policy_engine_mode = "any"
|
|
}
|
|
|
|
# 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.
|