Por qué un proxy¶

kubelatch se pone en el camino de cada petición a los API servers. Esta página explica qué otras formas de dar credenciales se estudiaron, por qué se descartaron y qué se paga a cambio de la elegida.

El problema¶

Lo que kubelatch tiene que resolver a la vez:

Credenciales por persona y por pipeline en clusters mixtos: EKS, GKE y AKS gestionados, y kubeadm, k3s, RKE2 o Talos propios.
Permisos por niveles con RBAC estándar.
Un inventario de credenciales: de quién es cada una, cuándo caduca, cuándo se usó por última vez.
Una auditoría por petición (verbo, recurso, namespace, resultado) igual en todos los clusters.
Credenciales cortas para CI sin secretos estáticos.

La condición que más recorta las opciones es la primera. En un cluster gestionado no controlas los flags del API server, así que cualquier mecanismo que los necesite no sirve para toda la flota.

Lo que se descartó¶

Alternativa	Por qué no
Certificados X.509 (CSR `kube-apiserver-client`)	Kubernetes no revoca certificados: un certificado emitido vale hasta que caduca. Además, EKS aprueba el CSR pero no emite el certificado.
OIDC en el API server	Exige flags o configuración del API server: solo es viable en clusters propios. GKE no admite un proveedor OIDC propio y en AKS está en preview. Y GitHub no es un proveedor OIDC para personas (su único emisor OIDC es el de Actions), así que haría falta interponer otro componente como Dex.
Webhooks de autenticación o autorización	Solo configurables en clusters propios.
Plugins `exec` de cada nube (IAM, gcloud, Entra)	Dan la identidad cloud de cada proveedor, no una credencial que kubelatch emita, inventaríe y revoque. Tres proveedores, tres inventarios.
Tokens nativos sin proxy (una ServiceAccount por persona y tokens `TokenRequest`)	Funcionan en todos los entornos y se revocan en segundos. Pero la auditoría por petición quedaría en la auditoría nativa de cada nube: tres formatos, minutos de retraso, coste por GB y, en GKE, sin lecturas por defecto. Y el «último uso» no se conoce sin leer esos logs.
Herramientas existentes (Teleport, Paralus, Pinniped, Rancher, el proxy de Tailscale…)	Ninguna gratuita junta inventario de credenciales vivas, auditoría por petición y credenciales de CI de primera clase. Las que lo cubren son plataformas pesadas, con licencias cambiantes o con precios de otro orden. Teleport Community Edition era la alternativa razonable si no se construía.

Lo que se eligió: impersonación¶

Solo dos mecanismos funcionan igual en los cuatro entornos sin tocar el API server: los tokens TokenRequest y la impersonación. La impersonación (impersonation en Kubernetes) es actuar en nombre de otra identidad. Es pura lógica del API server más RBAC: una ServiceAccount con el verbo impersonate envía Impersonate-User e Impersonate-Group, y el API server aplica el RBAC de la identidad impersonada.

Con un proxy que usa la impersonación:

Una sola vía para todos los clusters. Solo necesita RBAC estándar y una ServiceAccount por cluster.
Credenciales propias. El token lo emite y lo valida kubelatch. Revocar vale en la petición siguiente, y el inventario sabe el último uso real porque cada petición pasa por él.
Auditoría unificada, al momento y sin coste por GB. El proxy registra cada petición con el mismo esquema en todos los clusters.
Correlación con la auditoría nativa del cluster. El API server reutiliza el Audit-ID del proxy como su auditID, y registra a la persona como impersonatedUser.
RBAC nativo. El cluster sigue decidiendo cada verbo; kubelatch solo dice quién es la persona y en qué grupos está.

Es el mismo patrón que usan Pinniped (en clusters gestionados), Tailscale, NetBird, OpenUnison o StrongDM. No es un diseño exótico: es la única primitiva portable que pone a la aplicación en el camino de cada petición.

La prueba de que el patrón aguanta el uso real se hizo antes de escribir kubelatch: exec, cp, port-forward (por WebSocket y por SPDY), logs -f, un watch de más de dos minutos y un objeto de más de 1 MB, todo sobre TLS y a través del proxy.

Lo que cuesta¶

Poner un proxy en el camino tiene precio, y el diseño lo asume:

El proxy está en el camino crítico. Si kubelatch cae, las personas y la CI pierden el acceso a través de él (las cargas de trabajo no). Mitigación: dos réplicas, rollouts sin caída y un acceso nativo de emergencia a cada cluster.
Los streams largos exigen cuidado. Hace falta un transporte HTTP/1.1 dedicado para exec y port-forward, reenvío sin búfer para watch y logs -f, y nada de timeouts de lectura o escritura. Los intermediarios (balanceadores, Ingress) necesitan timeouts altos y sin límite de tamaño de cuerpo.
Hay trampas en la impersonación. El cliente de Kubernetes deja pasar una petición que ya traiga Impersonate-User; por eso el proxy rechaza cualquier Impersonate-* entrante y kubectl --as no está soportado. Y una credencial sin permisos ya sería un usuario autenticado para el API server, así que el proxy la bloquea antes.
La frontera de namespace sigue siendo débil. El proxy no cambia lo que RBAC permite dentro de un namespace (ver Niveles).
Los clusters privados tienen que ser alcanzables desde kubelatch. No hay relay propio: se documentan túneles (ver Clusters privados).

Lo que se dejó fuera a propósito¶

La simplicidad de kubelatch se decide en tres fronteras: la identidad se queda en GitHub, la autorización en el RBAC nativo y la auditoría profunda en el API server. Por eso kubelatch no tiene CA propia, ni proveedor de identidad propio, ni relay, ni grabación de sesiones. Es lo que ha hecho pesadas a las alternativas.

Los tokens TokenRequest nativos quedan como posible vía de escape futura para lo que no deba atravesar el proxy.

Para saber más¶

La investigación completa está en el repositorio, fuera de este sitio: docs/research/informe-credenciales-kubernetes-rbac-auditoria.md (el informe, con sus fuentes), las notas en docs/research/notas/ (mecanismos nativos, herramientas existentes, auditoría por entorno, proxy de impersonación, diseño RBAC, identidad y CI) y los resultados de la prueba del proxy en docs/research/spike-proxy-resultados.md.