02 01 auth authz

Autenticación y Autorización

¿Para quiénes son? Humanos (administradores, desarrolladores) o sistemas externos que intentan comunicarse con el clúster desde afuera.
Gestión: Kubernetes NO las gestiona. No existe un objeto User en la API (si haces kubectl get users, te dará error).
Autenticación: Kubernetes delega esto a sistemas externos. Se validan mediante certificados X.509 (lo que usas por defecto en tu archivo ~/.kube/config), tokens estáticos o proveedores de identidad como OIDC (Google, Azure AD).
Alcance (Scope): Son Globales. Un usuario llamado juan@empresa.com es el mismo en todos los namespaces del clúster.

¿Para quiénes son? Procesos, aplicaciones y Pods que se ejecutan dentro del clúster y necesitan permisos para hablar con el kube-apiserver.
Gestión: Kubernetes SÍ las gestiona. Son objetos nativos del clúster. Puedes crearlas, listarlas y borrarlas directamente.
Autenticación: Utilizan tokens JWT (JSON Web Tokens) que el propio clúster genera y firma automáticamente, montándolos dentro del sistema de archivos del Pod.
Alcance (Scope): Están limitadas a un Namespace. El ServiceAccount default del namespace desarrollo es completamente independiente del default del namespace produccion.

Característica	User Accounts (Usuarios)	ServiceAccounts (SA)
Audiencia	Humanos / Administradores	Pods / Aplicaciones internas
¿Objeto nativo en K8s?	❌ NO	✅ SÍ (kubectl get sa)
Alcance	Todo el Clúster	Restringido por Namespace
Cómo se crean	"Certificados externos (OpenSSL), OIDC"	`kubectl create sa <nombre>`

Inyección por defecto: Si no le dices nada a un Pod, Kubernetes le inyectará el token del ServiceAccount default de su namespace.
Hardening: Por seguridad, NUNCA debes dejar que los Pods monten tokens de la API si no los necesitan. El examen te pedirá que bloquees esto agregando automountServiceAccountToken: false en el YAML del Pod o del ServiceAccount.
Inmutabilidad: Un Pod no puede cambiar de ServiceAccount una vez que está corriendo. Tienes que matarlo y recrearlo si necesitas cambiarle la identidad.

Dado que Kubernetes no tiene un comando useradd, el proceso se basa en generar certificados criptográficos y configurar el archivo kubeconfig.

Paso 1: Generar credenciales locales (OpenSSL)

Se crea una llave privada (.key) y un Certificate Signing Request (.csr).
El truco del examen: En el certificado, el atributo CN (Common Name) define el nombre del usuario, y el atributo O (Organization) define el grupo al que pertenece.
Ejemplo: openssl req -new -key juan.key -out juan.csr -subj "/CN=juan/O=desarrolladores"

Paso 2: Solicitar firma al clúster (Objeto CSR)

Se crea un objeto nativo de tipo CertificateSigningRequest enviando el contenido del .csr codificado en base64 al kube-apiserver.
Esto permite usar la Autoridad Certificadora (CA) interna de Kubernetes en lugar de firmar archivos manualmente en el nodo Master.

Paso 3: Aprobar y extraer el certificado

El administrador debe aprobar explícitamente la petición para que el clúster firme el certificado.
Aprobar: kubectl certificate approve <nombre-csr>
Extraer: Una vez aprobado, se extrae el certificado final (.crt) consultando el estado del CSR con JSONPath y decodificando el base64.

Paso 4: Configurar kubeconfig

Se registran las nuevas credenciales en el archivo local de configuración para que kubectl sepa cómo presentarse.
Credenciales: kubectl config set-credentials juan --client-certificate=juan.crt --client-key=juan.key
Contexto (Unir usuario + clúster): kubectl config set-context juan-context --cluster=kubernetes --user=juan
Cambiar de identidad: kubectl config use-context juan-context

Resultado esperado de Seguridad:

Al usar el nuevo contexto e intentar hacer un kubectl get pods, el sistema arrojará un error "Forbidden".
Esto es correcto: demuestra que la autenticación fue exitosa (Kubernetes sabe que eres "Juan"), pero por denegación implícita, aún te falta la autorización (no tienes permisos).