Restringir y delegar el acceso

1. Origen de la necesidad

Hasta ahora, los recursos creados no tenían necesariamente espacios de nombres o restricciones de consumo. En el caso de un clúster utilizado por varios equipos, una buena práctica es separar las diferentes aplicaciones o entornos de aplicaciones utilizando espacios de nombres y adjuntarles medidas de seguridad.

En Kubernetes, estas medidas de seguridad adoptan la forma de cuotas y se pueden definir mediante dos tipos de límites:

A continuación, se muestran algunos ejemplos de definición de limitación:

Tenga en cuenta que establecer cuotas de recursos (ResourceQuota) en un espacio de nombres lo obligará a establecer limitaciones a nivel de los contenedores. Un contenedor/pod sin estas limitaciones no se puede desplegar ahí.

2. Cuotas por defecto en un espacio de nombres

$ kubectl create ns test 

$ kubens test 

1. Origen de la necesidad

La sección anterior se dedicó a implementar restricciones de acceso a nivel de espacio de nombres. Sin embargo, todos los accesos se realizaron con el mismo identificador.

Así, el archivo Kubeconfig se convierte en un recurso crítico, como una contraseña de root o una clave privada SSH.

Si bien en un equipo pequeño este tipo de incidente sigue siendo aceptable, en una organización más grande esta situación puede suponer un problema.

Los usuarios pueden ser autenticados usando varios mecanismos:

Algunos de estos accesos se basan en la configuración del servidor API de Kubernetes mediante el uso de opciones de arranque o la emisión de certificados, generados vía la infraestructura de clave privada del clúster (Private Key Infrastructure).

En adelante, se tratarán los siguientes mecanismos:

Finalmente, el lector abordará el uso de cuentas de servicio (objeto ServiceAccount). Este mecanismo se debe utilizar en el caso de llamadas externas, como cuando se emplean autómatas, por ejemplo.

2. Requisitos previos

Los ejercicios que siguen se basarán en la modificación de las opciones de inicio de la API de Kubernetes o la emisión de certificados basados en la clave del clúster. Naturalmente, este ejercicio no se puede realizar en un clúster gestionado debido a la imposibilidad de acceder a los certificados internos del clúster o a las opciones de inicio de la API.

Por lo tanto, es imprescindible que el clúster haya sido creado por usted (usando Kubespray o k3s, pero también con otros métodos como Kubeadm, Kops, Minikube, etc.) o, en todo caso, que disponga de los accesos necesarios. En adelante, el ejercicio se realizará en un clúster Minikube.

Otro requisito previo es que parte de los ejercicios demandará generar certificados utilizando OpenSSL. Por lo tanto, debe tenerlo localmente en su ordenador.

Los ejercicios no requieren necesariamente...

1. Presentación del mecanismo

En Kubernetes, no existe un tipo para representar a un usuario: se referencian directamente como un identificador (clemente, admin@mi-empresa.com) o un grupo (administrador, intranet, etc.).

En el resto del capítulo, se tratará el acceso mediante identificadores OAuth2.

2. Comunicación entre el proveedor OAuth2 y el clúster

La autenticación entre el clúster y el proveedor de identificadores se basa en el protocolo OpenID Connect (una extensión popular del protocolo OAuth2, compatible con Google o Azure).

La principal diferencia es la presencia de un campo que contiene un token de identificación de tipo JWT (JSON Web Token). Este token se utiliza para la autenticación del usuario y también puede contener campos adicionales, como la dirección de correo electrónico del usuario. Asimismo, está firmado por el proveedor de identidad.

Diagrama de comunicación entre el clúster de Kubernetes y el proveedor de Oauth2

3. Crear los identificadores

Primera etapa: crear identificadores de cliente para OAuth2. Esta operación se realiza desde la consola de Google (o cualquier otro proveedor de identidad).

Creación del identificador ID client OAuth

Recuperación de los identificadores después de crear el identificador ID client OAuth

4. Modificar las opciones de inicio (Minikube)

La modificación de las opciones de inicio del clúster sigue el mismo procedimiento que la habilitación del acceso anónimo.

$ minikube ssh 

$ sudo su - 

$ mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/. 

1. Contexto

Una buena manera de interactuar con un clúster de Kubernetes es hacerlo a través de una cuenta de servicio. Esta necesidad, generalmente, se justifica al implementar autómatas (despliegue continuo, compilación, auditoría de seguridad, monitoreo, etc.).

Sin embargo, se debe tener mucho cuidado con el uso de este tipo de acceso. El token de autenticación da licencia para realizar todas las operaciones permitidas por el usuario técnico.

Posteriormente, el lector creará una cuenta de servicio accesible desde fuera del clúster.

2. Crear la cuenta de servicio

Una cuenta de servicio se crea utilizando un objeto de tipo ServiceAccount. 

A continuación, se muestran los campos obligatorios:

A continuación, la declaración correspondiente:

apiVersion: v1 
kind: ServiceAccount 
metadata: 
  name: cicd 
  namespace: default 

$ kubectl apply -f cicd-account.yaml 

Un método alternativo es usar el comando kubectl create seguido de estas opciones:

A continuación, se muestra el comando correspondiente:

$ kubectl create serviceaccount --namespace default cicd 

3. Asignación de los permisos de administrador de la cuenta de servicio

La cuenta ahora debe estar asociada al rol cluster-admin. Este enlace se realizará mediante un objeto ClusterRoleBinding. Dicho objeto está estructurado de la siguiente manera: