Un material publicado en el blog de la CNCF recomienda considerar el control de acceso a los clústeres de Kubernetes como parte de la configuración básica, junto con las redes y el almacenamiento, especialmente en entornos autogestionados que normalmente no ofrecen una integración IAM o SSO lista para usar, como sucede con los servicios de Kubernetes gestionados. La idea central es utilizar un proveedor de identidad compatible con OIDC, como Keycloak, y registrar el cliente como un cliente público que utiliza PKCE, no como un cliente confidencial que contenga una clave compartida.
En muchos clústeres locales, el acceso depende de un certificado de cliente estático o de un token de larga duración emitido una sola vez. Estos datos siguen siendo válidos incluso después de que el empleado abandone la organización, cambie de función o pierda el dispositivo que los contiene. Además, revocar el acceso requiere encontrar cada copia del archivo de certificado o del token, una tarea cuya integridad resulta difícil de garantizar cuando hay varios dispositivos y usuarios. A medida que aumenta el número de personas y varían los niveles de permisos, distribuir y gestionar los archivos se convierte en una tarea operativa continua.
¿Qué cambia con OIDC?
En lugar de vincular el permiso a un archivo de certificado, este pasa a estar asociado con la cuenta del usuario y su pertenencia a grupos del proveedor de identidad. La integración consta de tres partes interrelacionadas: la herramienta kubectl con el complemento kubelogin o kubectl oidc-login; el proveedor de identidad, que autentica al usuario y emite el token de identidad; y el servidor kube-apiserver, que valida el token, extrae el nombre de usuario y los grupos, y deja que Kubernetes RBAC determine las operaciones permitidas.
kubectl no se conecta primero al servidor de API para iniciar el inicio de sesión. El complemento exec-credential inicia el inicio de sesión mediante el navegador en el proveedor de identidad y después devuelve el token de identidad a kubectl para enviarlo como credencial de portador. El servidor de API valida el token utilizando las claves públicas de firma del proveedor de identidad. Según el material, el servidor no necesita una conexión permanente con el proveedor de identidad, salvo para obtener esas claves cuando sea necesario.
¿Por qué debe ser público el cliente?
El cliente confidencial emite una clave que se añade a la configuración del complemento kubelogin y se distribuye a cada dispositivo que necesita acceso. El material considera que una clave que debe distribuirse a todos los clientes ya no es realmente un secreto, sino una credencial estática compartida difícil de rotar. En cambio, para las aplicaciones de línea de comandos y las aplicaciones nativas, la opción más adecuada es un cliente público sin secreto, con PKCE, o Proof Key for Code Exchange, habilitado.
El cliente genera un valor aleatorio localmente y envía un hash de este en la solicitud inicial de inicio de sesión; después demuestra que posee el valor original al intercambiar el código de autorización por un token de acceso. Por ello, quien intercepte únicamente el código de autorización no puede completar el proceso. La configuración de Keycloak incluida en el material propone desactivar la autenticación del cliente, activar el flujo estándar, desactivar las concesiones de acceso directo y exigir PKCE mediante S256, además de limitar las direcciones de redirección y los orígenes web a direcciones de loopback como 127.0.0.1 y localhost.
Pasos básicos de configuración
- Añadir el mapeador de pertenencia a grupos al ámbito del cliente en Keycloak, de modo que aparezca una afirmación con el nombre groups dentro del token de identidad.
- Configurar kube-apiserver mediante indicadores como oidc-issuer-url, oidc-client-id, oidc-username-claim y oidc-groups-claim.
- Añadir oidc-ca-file si el proveedor de identidad utiliza un certificado no firmado por una autoridad pública de confianza, para que el servidor de API pueda validar la conexión TLS y obtener las claves de firma.
- Modificar kubeconfig para utilizar una entrada exec-credential mediante kubectl oidc-login en lugar de incluir certificados o tokens estáticos, sin añadir un campo secreto.
- Vincular los grupos del proveedor de identidad con roles de Kubernetes RBAC, por ejemplo, vinculando el grupo platform-viewer con el rol view.
Impacto práctico y limitaciones
Después de esta vinculación, los cambios de acceso se realizan dentro del proveedor de identidad: se añade o se elimina al usuario de un grupo, en lugar de modificar el clúster o redistribuir kubeconfig. El siguiente token emitido al usuario obtiene la nueva pertenencia al grupo y se aplica la regla de RBAC asociada. El material explica que el primer inicio de sesión abre el navegador, mientras que kubelogin reutiliza el token almacenado en caché hasta que caduca; después utiliza el token de actualización sin iniciar una nueva interacción con el navegador. La identidad y los grupos efectivos pueden comprobarse mediante el comando kubectl auth whoami.
Esto no significa que la integración carezca de requisitos operativos. Es necesario configurar con precisión la afirmación de grupos, validar el certificado del proveedor de identidad, limitar las direcciones de redirección y asegurarse de que los roles de RBAC reflejen los permisos necesarios. Además, el material no ofrece mediciones independientes del tiempo de configuración ni del coste operativo, sino que estima que la preparación podría completarse durante una sola jornada laboral, sin realizar una migración completa de la plataforma.
El principal beneficio administrativo y de seguridad es que los registros de Kubernetes quedan vinculados a la identidad real del usuario. Los registros que dependen de una cuenta general como cluster-admin no distinguen entre quienes ejecutan las solicitudes, mientras que cada solicitud emitida mediante OIDC contiene el nombre del usuario y los grupos asociados. Esta es una lectura editorial basada en los detalles del material: la mejora no se produce únicamente en la forma de iniciar sesión, sino también en la capacidad de atribuir las acciones a sus responsables, haciendo que la concesión y la revocación de permisos sean un proceso de identidad centralizado en lugar de una búsqueda de archivos de credenciales distribuidos.