Vers la 0.5.0

La 0.5.0 ajoute upstream_auth (RFC 0014) : un cluster peut faire croire à son apiserver l'identité affirmée par le proxy, en en-têtes (Apiserver en front-proxy) ou dans un JWT que le proxy signe (Le proxy comme émetteur), au lieu de lui relayer le jeton de l'IdP. Rien ne change sans action de l'admin du proxy : upstreamAuth.allowedModes vaut [Passthrough].

Mettre à jourCopy Anchor Link

Comme toujours, chart-crd avant le chart, et toute l'installation à jour avant qu'un cluster quitte Passthrough :

helm upgrade proxyauthk8s-crd oci://ghcr.io/batleforc/proxyauthk8s/chart-crd:0.5.0 \
  --namespace ${NAMESPACE}
helm upgrade proxyauthk8s oci://ghcr.io/batleforc/proxyauthk8s/chart:0.5.0 \
  --namespace ${NAMESPACE} \
  --values proxyauthk8s-values.yaml

Le contrôleur refuse de démarrer sur une CRD qui ne connaît pas upstream_auth, avec un message qui nomme la version de chart-crd attendue.

Si vous gérez le RBAC vous-même, le compte du serveur a besoin, sur les secrets du namespace de la release, de get (le certificat FrontProxy) et de list, create, update et delete (les clés Issuer, que le contrôleur crée, fait tourner et balaie). L'Ingress du chart route désormais /issuer/ vers le back : à reporter si vous exposez le proxy autrement.

Ce qui change pour tous les clustersCopy Anchor Link

• Cache des jetons : sa clé inclut désormais le claim_mappings du cluster. Le cache est vidé au déploiement : une revalidation par utilisateur.
• Sous-protocole WebSocket : une entrée base64url.bearer.authorization.k8s.io.* de Sec-WebSocket-Protocol n'est plus relayée à l'apiserver. kubectl envoie Authorization et n'est pas touché ; un client qui ne s'authentifierait que par ce sous-protocole reçoit 401.
• /userinfo : une réponse de plus de 64 Kio (PROXY_JWKS_MAX_DOCUMENT_BYTES) est refusée.
• Colonne Upstream dans kubectl get proxykubeapi -o wide (status.upstreamAuth.mode) ; vide, elle signale un contrôleur trop ancien.

Ajouter claim_mappings à un cluster existantCopy Anchor Link

oidc_provider.claim_mappings est optionnel en Passthrough, requis en FrontProxy. L'ajouter change le nom vu par le proxy (par exemple de preferred_username à sub) : revoyez les allow-lists par nom, le rate limit par sujet et la continuité de l'audit, et, en FrontProxy, les RoleBinding du cluster cible, qui visent user_prefix + ce nom. kubectl auth whoami affiche le nom que l'apiserver voit.

En FrontProxy, un utilisateur de plus de 64 groupes reçoit 403 : filtrez par groups.expression avant la bascule (fréquent avec Active Directory).

Revenir en arrièreCopy Anchor Link