El SSO del cluster, proveedor a proveedor¶

Qué nombres da a usuarios y grupos dentro del cluster cada forma de iniciar sesión en él, y qué plantilla de identidad y qué grupos de rol nativo le van bien. Por qué existen estas dos piezas lo cuenta kubelatch encima del SSO que ya tienes.

Antes de empezar¶

• Usa los nombres que usa de verdad el cluster. «Lo que este cluster conoce», en la página del cluster, muestra los grupos y usuarios que nombran sus bindings y a qué está enlazado cada uno. Para tu propio nombre, ejecuta kubectl auth whoami con el kubeconfig del propio cluster.
• {email} y {oidc_subject} salen de la identidad de cada cuenta en el proveedor OIDC de kubelatch. Para que casen con los nombres del cluster, kubelatch y el cluster confían en el mismo proveedor de identidad, y el cluster lee el correo verificado para {email}, o el claim de OIDC_SUBJECT_CLAIM para {oidc_subject}.
• Una cuenta sin identidad en el proveedor recibe un 403 en ese cluster hasta que entra una vez con él (Cuentas que no se pueden nombrar).

k3s, kubeadm y otros clusters con su propio OIDC¶

El apiserver confía en un proveedor de OpenID Connect con sus opciones --oidc-*, o con un fichero AuthenticationConfiguration que se le pasa con --authentication-config:

En k3s cada opción va con --kube-apiserver-arg, sin sus guiones iniciales: --kube-apiserver-arg=oidc-username-claim=email.

Un cluster configurado con --oidc-username-claim=email --oidc-username-prefix=oidc: --oidc-groups-claim=groups --oidc-groups-prefix=oidc: nombra a Ana oidc:ana@acme.com y a sus grupos oidc:developers y oidc:platform-admins. Entonces:

• Plantilla: oidc:{email}.
• Roles nativos: oidc:developers y los demás grupos tal como los nombra el cluster, con su prefijo.

Si el claim del nombre de usuario se queda en sub, la plantilla es el prefijo seguido de {oidc_subject}, y el OIDC_SUBJECT_CLAIM de kubelatch también es sub.

EKS¶

Con access entries o con aws-auth, los principales de IAM reciben un nombre de usuario de Kubernetes y una lista de grupos (kubernetesGroups, o groups en aws-auth). Con IAM Identity Center el nombre de usuario es el ARN de la sesión, no el correo.

• Plantilla: deja user:{login}.
• Roles nativos: los grupos que nombran tus RoleBindings y ClusterRoleBindings, como eks-developers.

Con un proveedor OIDC asociado al cluster, elige la plantilla y los grupos como en k3s, con los prefijos que pusiste al asociarlo.

AKS con Microsoft Entra ID¶

Los bindings del cluster nombran los grupos de Entra por su object id, un GUID como 5d0f7b6e-….

• Roles nativos: esos object ids. Usa el nombre y la descripción del rol para decir qué grupo es cada uno.
• Plantilla: {email}, porque Entra nombra por defecto a los usuarios por su UPN, el nombre con el que entran. Usa {oidc_subject} con OIDC_SUBJECT_CLAIM=oid solo si el cluster nombra a los usuarios por su object id.

Con Azure RBAC for Kubernetes Authorization, el acceso lo deciden las asignaciones de roles de Azure y no los bindings, así que el cluster no tiene bindings que kubelatch pueda leer.

GKE¶

GKE nombra a las personas por el correo de su cuenta de Google y, con Google Groups for RBAC, a los grupos por el correo del grupo.

• Plantilla: {email}, con kubelatch dejando entrar a la gente por Google Workspace.
• Roles nativos: los Google Groups que nombran tus bindings, como gke-devs@acme.com.

DigitalOcean (DOKS)¶

DOKS nombra a las personas por el correo de su cuenta de DigitalOcean, y su rol en el equipo llega como un grupo do-role-name:<rol>.

• Plantilla: {email}.
• Roles nativos: esos grupos.

De un vistazo¶

Sea cual sea el proveedor, un grupo o un usuario que el cluster enlaza a cluster-admin sigue la regla de las 8 horas (El nombre arrastra todo lo que el cluster le enlaza).