La gestión segura de secretos en AKS

Resumen

La gestión segura de los secretos es fundamental para las organizaciones que utilizan aplicaciones nativas de la nube.
En este artículo, integramos Azure Key Vault con AKS para garantizar una gestión adecuada de los secretos a través de Terraform.
Puedes encontrar el enlace al repositorio de GitHub: aks-keyvault

Requisitos previos

• Suscripción a Azure
• AZ CLI
• Terraform

Puedes clonar el repositorio y ejecutar los scripts de Terraform para aprovisionar la infraestructura.

Diseño de bajo nivel

Analicemos más detenidamente los componentes clave:
Redes virtuales (VNets):
En nuestra configuración tenemos dos VNets diferentes:

• Uno para AKS (donde se encuentra nuestro clúster de Kubernetes).
• Uno para Key Vault (donde se almacenan todos nuestros secretos).

Estas VNets están interconectadas, lo que significa que pueden comunicarse entre sí de forma segura a través de la red privada de Azure.
Dos elementos clave para facilitar y hacer posible la comunicación:

1. Peering: El peering entre la VNet de AKS y la VNet de Key Vault permite una comunicación directa y fluida. Esto significa que los recursos de ambas VNet pueden interactuar sin pasar por Internet, lo que garantiza una latencia reducida y un mejor rendimiento.
2. Punto de conexión privado: Se ha creado un punto de conexión privado para Azure Key Vault. Este desempeña un papel crucial al permitir un acceso seguro a Key Vault a través de una dirección IP privada perteneciente a la misma red virtual (VNet). Esto garantiza que las solicitudes enviadas desde la red virtual de AKS a Key Vault permanezcan dentro de la red troncal de Azure, protegiendo así los datos confidenciales frente a amenazas externas. Además, los pods/aplicaciones de la VNet de AKS pueden utilizar identidades gestionadas para autenticarse, lo que simplificará la gestión de accesos.

Dentro de la VNet de AKS:
En esta red, hemos implementado nuestro clúster de Kubernetes.
Supongamos ahora que su pod es su aplicación, que necesita un secreto determinado.
Cada pod funciona mediante una cuenta de servicio (SA). Esta SA es importante porque determina quién (o qué) tiene permiso para acceder a recursos como los secretos que pertenecen a Azure Key Vault.

A continuación, utilizamos el controlador Secret Store CSI para que nuestra aplicación pueda recuperar secretos de Key Vault y montarlos como volúmenes en los pods. De este modo, la aplicación puede utilizar estos secretos como archivos normales, o incluso como variables de entorno.

¿Cómo acceden los pods a los secretos?

Aquí es donde entra en juego la seguridad:
Cada SA está vinculada a una identidad gestionada asignada al usuario (UAMI), que es como una «tarjeta de identidad especial» que Azure asigna a nuestros pods.
Azure Key Vault reconoce esta identidad y concede al pod acceso a los secretos en función de los permisos definidos en la UAMI.

Integración de la identidad federada y UAMI en AKS y Azure Key Vault

Para proteger el acceso a los servicios de Azure a través de AKS, es fundamental comprender la identidad federada y la identidad gestionada asignada al usuario (UAMI). A continuación se ofrece un resumen de estos conceptos y de su papel en la seguridad de las aplicaciones.

¿Qué es una identidad gestionada?

Una identidad gestionada permite a las aplicaciones autenticarse en otros servicios de Azure sin tener que gestionar directamente las credenciales. Existen dos tipos:

• Identidad gestionada asignada por el sistema: se crea automáticamente para un recurso específico y se elimina junto con este.
• Identidad gestionada asignada por el usuario (UAMI): Se crea de forma independiente y puede compartirse entre varios recursos, lo que ofrece una mayor flexibilidad.

¿Por qué utilizar UAMI?
UAMI simplifica el acceso a los recursos de Azure para varias aplicaciones, lo que permite una gestión centralizada de los permisos y evita tener que incluir información confidencial en el código.

¿Qué es la identidad federada?
La identidad federada establece una relación de confianza entre las cargas de trabajo de AKS y Azure Active Directory, lo que permite una autenticación segura en los servicios de Azure.

Función de la identidad federada

• Establecimiento de la confianza: permite a los pods acceder a los servicios de Azure sin necesidad de introducir credenciales manualmente.
• Autenticación simplificada: La cuenta de servicio de AKS puede utilizar UAMI para acceder a los recursos de Azure.
• Seguridad reforzada: evita el almacenamiento de información confidencial en el clúster, protegiendo así las aplicaciones.

En la siguiente configuración de Terraform, hemos creado un secreto en Azure Key Vault denominado MYSQL-DB-PASSWORDD que intentaremos recuperar más adelante en el pod de AKS. A continuación, hemos creado una UAMI para permitir que nuestro clúster de AKS acceda a Azure Key Vault. Una asignación de rol le otorga permisos, y una identidad federada vincula la cuenta de servicio de AKS con el UAMI, lo que facilita la autenticación segura sin integrar credenciales sensibles.

Este enfoque utiliza el control de acceso basado en roles (RBAC) para definir los permisos de acceso a Key Vault. Gracias al RBAC, podemos asignar roles específicos a los usuarios y a los servicios, lo que garantiza un control de acceso granular y una mayor seguridad de los recursos. Esto facilita la gestión de los accesos a lo largo del tiempo, alineando los permisos con los roles y las responsabilidades de los servicios, en lugar de gestionar accesos individuales mediante políticas de acceso que pronto quedarán obsoletas.
Este código de Terraform resume los conceptos explicados:

En este ejemplo, se ha asignado el rol de administrador de Key Vault a nuestro UAMI, pero es posible sustituirlo por el rol de lector de Key Vault para adoptar un enfoque más restrictivo.

Y asegúrate de indicar correctamente el nombre de la cuenta de servicio y el espacio de nombres que se van a crear.

Antes de crear nuestra SA, obtén el clientId utilizando el siguiente comando y asegúrate de sustituirlo en el archivo sa.yml, dentro de azure.workload.identity/client-id: "" : 

A continuación, obtén el tenantId y sustitúyelo en secretprovider.yml

Asegúrate de utilizar el nombre de objeto correcto, que es MYSQL-DB-PASSWORDD, ya que lo hemos creado previamente con Terraform. También puedes hacer referencia a tantos secretos como sea necesario.

A continuación se muestra un ejemplo de configuración para hacer referencia al secreto en tu archivo YAML:

Tipos de ObjectType

El atributo `objectType` puede adoptar principalmente tres valores posibles:

• secreto: Se refiere a información sensible, como contraseñas, claves API o tokens, que debe mantenerse confidencial.
• clave: Se refiere generalmente a las claves criptográficas que se utilizan para cifrar o firmar datos.
• cert: Se refiere a los certificados, que se utilizan para autenticar identidades en las redes (como los certificados SSL/TLS).

Creación de un pod para acceder a los secretos montados desde Azure Key Vault

Ahora que hemos configurado nuestra clase SecretProviderClass y la hemos vinculado a Azure Key Vault, es el momento de crear un pod que utilice los secretos almacenados en Key Vault. Aquí es donde surge la magia, ya que podemos aprovechar nuestra cuenta de servicio para acceder de forma segura a esos secretos.

Configuración del pod «
» Esta es la configuración de nuestro pod:
kubectl apply -f pod-poc-vault.yaml

Y, por fin, podemos ver nuestra contraseña tan segura 😉:

Ha logrado crear un clúster de AKS, configurar redes virtuales e integrar Azure Key Vault para una gestión segura de los secretos. Ahora sus aplicaciones pueden acceder de forma segura a los secretos gracias al controlador Secret Store CSI, lo que hace que su implementación de Kubernetes sea más segura y eficiente.

Sofiene GHARBI
Ingeniero consultor en ciberseguridad