Authentification

La chaîne d'authentification du cluster, tirée du rendu Helm des applications Argo CD (comme les flux réseau), des CRs de l'opérateur weebo-authentik, de la configuration Pulumi de l'apiserver et d'Argo CD, et du kubeconfig du dépôt.

Fournisseur d'identité : Authentik (https://auth.weebo.poc), géré par CRs dans 2.argo/helm/auth/sub. Tout le reste s'y raccroche, directement ou par un Dex.

• Applications Authentik : chaque client, ses consommateurs et la façon dont le secret leur parvient.
• Groupes et accès : qui ouvre quoi, et ce que chaque groupe donne en aval.
• Flux Authentik : les flux, les blueprints, le second facteur.
• Kubernetes : de kubectl aux RoleBindings.
• Argo CD : connecteurs, rôles, projets et ce que chacun permet.

LégendeCopy Anchor Link

• Un groupe donne accès à une application Authentik par une politique d'accès (AuthentikAccessPolicy). Les membres d'un groupe enfant passent aussi les politiques de ses parents : weebo_admin ⊂ weebo_moderator ⊂ weebo_user.
• Une flèche Authentik → consommateur suit le client OIDC : l'opérateur écrit client_id/client_secret dans Vault (secretTargets), un ExternalSecret ou une injection vault: le relit dans un namespace, et l'objet qui nomme ce Secret est le consommateur. Une URL /application/o/<slug>/ en dur compte aussi.
• Une flèche épaisse (==>) passe par une étape de second facteur (flux d'autorisation à étape authenticator_validate, ici admin-step-up).
• Les Dex sont des courtiers : ils se connectent à Authentik comme un client, puis émettent leurs propres jetons à leurs clients statiques.
• Les proxys Authentik sont servis par le middleware Traefik forwardAuth : l'IngressRoute n'atteint le backend qu'après l'avant-poste Authentik.
• Côté Kubernetes, l'apiserver accepte deux émetteurs JWT (AuthenticationConfiguration de 1.pulu-init), et les (Cluster)RoleBindings donnent les droits aux noms préfixés qu'ils produisent.

Chaîne globaleCopy Anchor Link

ApplicationsCopy Anchor Link

Charts non rendusCopy Anchor Link

• aucun