Introducción

No se si a todo el mundo le pasa, pero siempre tuve un problema con estas dos palabras y conceptos "Authentication - Authorization". Había una cosa mística que no me permitía entender bien las diferencias y en todo caso saber, hablando de seguridad en nuestros sistemas, si se debía utilizar una la otra o ambas :) Hoy considero que el ejemplo del parque de diversiones nos puede ayudar a, de una vez y para siempre, comprender estos conceptos.

Disney para la autenticación y la autorización

El ejemplo es super simple, imaginemos que queremos ir a un parque de diversiones.

Viajamos al lugar y hacemos la fila para pagar nuestra entrada.

Una vez que pagamos esa entrada ya sin darnos cuenta nos estan de algún modo AUTENTICANDO para poder ingresar al parque. En la entrada nos preguntaron nuestros datos, nos pidieron nuestro documento de identificación. En definitiva el parque validó que yo soy quién dije ser!

El problema que tenemos es que al momento de ver la mejor montaña rusa del parque y querer ingresar, nos indican lo siguiente:

• El pase que usted adquirió no dispone de acceso para este juego, puede hacer un pago adicional para poder subir y disfrutar de nuestra montaña rusa!

WOW!!! Que sucedió?

Simplemente en nuestro pago inicial de la entrada al parque, obtuvimos la AUTENTICACION para ingresar, pero no la AUTORIZACION para poder jugar en esa montaña rusa.

En conclusión, el echo que un sistema valide que vos sos quién decis ser, no implica que puedas hacer cualquier cosa en el mismo.

Validar quién sos es parte de la AUTENTICACION del usuario. Verificar que puede o no hacer en el sistema ese usuario es parte de la AUTORIZACION que tiene ese usuario sobre el sistema.

Aplicación práctica en Kubernetes RBAC

Kubernetes utiliza "Role-based access control", para manejar el acceso a esta gran API que es kubernetes, esto nos permite una gran granularidad a la hora de entregar permisos. Veamos un ejemplo simple.

Tenemos en este caso una definición de un rol que nos permite realizar ciertas acciones sobre la API de kubernetes. Más precisamente sobre el recurso "pods" podemos hacer "get", "watch", "list" dentro del namespace default.

```apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules:

• apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"] ```

Ahora imaginemos al usuario Jane, persona AUTENTICADA dentro del cluster, pero sin permisos, pagó la entrada al parque pero sin incluir nungún juego!

Cómo podemos darle permisos a Jane? Creando lo que se llama en Kubernetes RoleBinding, que no es más que asignar un rol a ciertos "usuarios".

En este caso asignamos al usuario Jane el rol que creamos anteriormente con nombre pod-reader, y a partir de aquí Jane ya tiene permiso para ciertos "juegos" dentro del sistema!

```apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects:

• kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ```

Conclusión

Espero que este ejemplo sencillo nos permita comprender estos conceptos, que por lo menos a mí (alguien que no es especialista ni mucho menos en seguridad) me ayudó bastante!