Skip to main content

Autenticación

¿Cuáles son los posibles tipos de usuarios que tenemos en el cluster?

  • Admins: Son aquellos que acceden al cluster para tareas más administrativas. Generalmente poseen acceso completo al cluster.
  • Developers: Acceden al cluster para probar o implementar aplicaciones.
  • End Users: Acceden a las aplicaciones que están corriendo en el cluster.
  • Bots: Son otras aplicaciones de terceros que acceden a las aplicaciones en el cluster para fines de integración.

Es necesario proteger la comunicación entre los componentes internos y el acceso de esos posibles usuarios por medio de mecanismos de autenticación y autorización.

Los usuarios de las aplicaciones son administrados por las propias aplicaciones entonces vamos a removerlos de este escenario.

Entonces quedamos con dos tipos de usuario, que son los

  • Humanos:
    • admins
    • developers
  • Aplicaciones (servicios, procesos, aplicaciones, etc)

Para las aplicaciones usamos los ServiceAccounts de Kubernetes, pero no podemos crear un usuario con un comando kubectl create user david. Es necesario una fuente externa que validará un usuario y permitirá a él el uso de alguna role dentro del cluster. Podríamos usar por ejemplo un LDAP.

Todo acceso del usuario es administrado por el kube-apiserver, accediendo vía kubectl o vía api no importa.

El kube-apiserver autentica al usuario antes de procesar el pedido.

Alt text

Pero ¿cómo el kube-apiserver hace esa autenticación?

  • Archivo de password estático.
  • Archivo de token estático.
  • Certificados
  • Servicios de identidad como LDAP, Kerberos, etc

Alt text

Password y Tokens Estáticos​

Este método fue DESCONTINUADO en la 1.19 y ni siquiera entrará en el examen, pero vale para una primera introducción sobre el asunto.

Es necesario crear un archivo csv con las columnas password, username y userid. La última columna de groups es opcional

Por ejemplo user-details.csv con el contenido abajo.

abcd123,david,u0001,group1
asdf4321,joao,u0002,group1
4321qwer,maria,u0003,grou2

También es posible crear el archivo de token, por ejemplo creando un archivo token-details.csv

Kuandfa1AD123ava234adavc12,david,u0010,group1
dDAar1435ASAdvcra32314dcca,joao,u0020,group1
Adafa13279DiiyrteuYUTR345c,maria,u0030,grou2

El kube-apiserver necesita subir sabiendo dónde estos archivos se encuentran pasando la flag --basic-auth-file=user-details.csv y --token-auth-file=token-details.csv. No es necesario pasar ambos, pues son apenas métodos diferentes de autenticación.

Si estuviera corriendo como un servicio deberíamos pasar así. Es necesario reiniciar el servicio para hacer efecto.

Alt text

Si estuviéramos corriendo el kube-apiserver por medio de pods, por ejemplo lanzado por kubeadm, es necesario modificar el pod del kube-apiserver.yaml. La herramienta kubeadm automáticamente reiniciará el kube-apiserver con las nuevas modificaciones.

Alt text

Para utilizar el kubectl con autenticación de usuario y contraseña necesitamos pasar el usuario y contraseña.

kubectl get pods --username=david --password=abcd123
#vía api password y contraseña (david)
curl -v -k https://master-node-ip:6443/api/v1/pods -u "david:abcd123"
#vía api token (joao)
curl -v -k https://master-node-ip:6443/api/v1/pods --header "Authorization: Bearer: dDAar1435ASAdvcra32314dcca"

O en nuestro .kube/config el usuario para el cluster sería así, entonces no necesitaríamos pasar el usuario y contraseña a cada comando.

clusters:
- name: mi-cluster
  cluster:
    server: https://direccion-del-cluster
 ...
contexts:
- name: joao-token
  context:
    cluster: mi-cluster
    user: joao
- name: david-password
  context:
    cluster: mi-cluster
    user: david
current-context: joao-token

users:
- name: david
  user:
    auth-provider:
      name: "basic-auth"
      config:
        username: david
        password: abcd123
- name: joao
  user:
    auth-provider:
      name: "token"
      config:
        token: dDAar1435ASAdvcra32314dcca

Esos métodos no son recomendados y son considerados inseguros, principalmente con contraseñas y tokens muy fáciles de ser utilizados en ataques de fuerza bruta. Almacenar contraseñas y tokens en archivos nunca fue una opción segura.

Debe ser considerado pasar el path donde los archivos fueron creados.