El acceso a los secretos siempre es uno de los puntos clave en los entornos Kubernetes y tenemos varias herramientas para poder almacenarlos haciendo uso de servicios externos. En este artículo veremos cómo usar Azure Key Vault como almacén de secretos y certificados.
Haciendo uso de un Secret Store Provider vamos a montar los secretos directamente desde el Azure Key Vault sin tener que preocuparnos de que nuestras aplicaciones tengan que tener la lógica necesaria para acceder a los mismos.
Dentro del pod se leerán como variables de entorno o se montarán como rutas de manera que podemos cambiar el provider de secretos sin tener que tocar las aplicaciones desplegadas.
La ventaja que sacamos de esto es romper dependencias de nuestro código a servicios concretos y evitar así tener que pasar credenciales o permisos de lectura a los desarrolladores para cualquier entorno.
Creación del cluster AKS
Vamos a desplegar un nuevo cluster donde habilitaremos las managed identity y usaremos el plugin Azure para la red.
El network plugin azure es necesario para poder asignar una managed identity a los pods que desplegaremos.
Esa identidad es la que usará para conectar con el Azure Key Vault.
Obtenemos las credenciales asignadas al cluster. Con esto podemos empezar a usar kubectl desde nuestra terminal.
Instalación Helm
Para dejarlo ya preparado añadiremos los repositorios de los paquetes Helm que vamos a utilizar.
CSI Secrets Store Provider Azure
Nos permite crear secrets store providers con Azure Key Vault.
AAD Pod Identity
Lo utilizaremos para asociar la manage identity a los pods para permitir el acceso al Key Vault.
Permisos de Managed Identity Operator
Un punto importante que tenemos que configurar es permitir a la identidad del Kubelet del cluster tenga los roles de Managed Identity Operator y Virtual Machine Contributor en los grupos de recursos del cluster, y así poder asignar en los nodos las identidades que seleccionemos más adelante para que usen los pods.
Si el cluster donde estamos haciendo esto, ya tiene habilitada la opción de managed identity es posible que ya esté configurado y no tengamos que hacerlo.
Creación de Pod Identity
A continuación, creamos la identidad que asignaremos a los pods y desplegamos el helm de aad-pod-identity
Si inspeccionamos los pods desplegados debe tener este aspecto:
Si no hemos desplegado el cluster con el Network plugin de Azure al hacer la instalación el estado de los pods uno de ellos quedará crasheado.
Y viendo el log del pod crasheado, vemos que nos indica claramente que no está soportado para Kubenet
Asignación de permisos al pod identity
Seguidamente lo que debemos hacer es darle permisos de lectura a la identidad que hemos creado para los pods en el Azure Key Vault.
En este caso el Key Vault ya existe y ya tiene cargados los certificados y los secretos que vamos a utilizar en esta demo.
Obtenemos el clientId de la identidad que hemos creado para los pods y el id del Key Vault
A continuación, proporcionamos el acceso al recurso del Key Vault
Y damos acceso a la identidad manejada a la obtención de los valores de los secretos, claves y certificados del Key Vault
Creación de la identidad dentro del cluster
Una vez hecho esto, ya tenemos nuestros recursos en Azure para poder consumir dentro del cluster.
- Managed Identity para los pods
- Key Vault
- Permisos del Managed Identity en el KV
Ahora debemos de crear recursos dentro de nuestro cluster y el primero de ellos es un AzureIdentity y un AzureIdentityBinding
AzureIdentity: Recurso que establece la managed identity a utilizar
AzureIdentityBinding: Generamos el selector que tendremos que poder en los recursos desplegados para usar la AzureIdentity
Para hacer esto necesitaremos obtener el id de la identidad que hemos creado y usarlo dentro del taml del AzureIdentity
Storage Provider
Bien, ya somos capaces de asignar la identidad que tiene acceso al Key Vault a los elementos desplegados del cluster.
Pero ahora, ¿cómo accedemos al Key Vault?
Para poder montar los secretos, debemos dar de alta un Storage Provider usando el helm que hemos instalado al principio:
Cuando lo hayamos instalado, el siguiente paso es definir un Storage Provider usando el nuevo driver dentro de nuestro cluster. En este Storage Provider definiremos a que secretos concede acceso el provider y de que Key Vault.
El Secret Provider tiene dos partes a configurar:
- secretObjects: Son los secretos a los que se podrá acceder haciendo uso del secret provider dentro de los elementos desplegados en el cluster.
- objects: Define los elementos del Key Vault a los que queremos dar acceso.
Tal y como tenemos definido el Secret Provider Class, nuestro secret MyKeyVaultSecretParameter vamos a darle visibilidad dentro del cluster con el nombre MySecretParameter, lo que nos permite proporcionar el acceso a secretos sin que ni siquiera los equipos de desarrollo conozcan su nombre original.
Para comprobar que podemos utilizar el contenido del Key Vault como inline secret store y como variables de entorno vamos a desplegar el siguiente pod:
La imagen que vamos a utilizar es enriquecatala/fastapi-helloworld que pertenece a mi compañero Enrique Catalá y viene muy bien para testear este tipo de desarrollos.
Es una API muy sencilla donde hay dos métodos GET que devuelven el valor de la variable de entorno.
Podéis ver el código en su GitHub https://github.com/enriquecatala/fastapi-helloworld
Usando el secret provider que hemos generado anteriormente, montamos un volumen con el driver de secrets-store que ya tenemos configurado.
Hará uso de la identidad que le estamos poniendo al pod en el label aadpodidbinding: gperez-demo-kv-identity-binding-selector y será accesible dentro del contenedor en la ruta /mnt/secrets-store.
Para hacer referencia cargar uno de los secretos como variable de entorno utilizaremos el atributo key que hemos establecido en el secretsObjects.data del Secret Provider
Una vez tenemos desplegado el Pod podemos ver que el Secret kv-secret se ha generado cuando el primer pod lo ha solicitado, no cuando hemos desplegado el Secret Provider.
Si lanzamos un comando ls sobre la ruta en la que hemos montado el secret store, podemos ver que están los secretos que hemos definido
Y si usamos el comando port-forward para acceder a la API que el pod tiene desplegada en el puerto 5000, podemos comprobar que el valor de la variable de entorno es que le tenemos definido en el Key Vault:
Conclusión
Haciendo uso de Azure Key Vault hemos conseguido sacar fuera del cluster el almacenamiento de secretos de nuestras aplicaciones además de quitar a los equipos de desarrollo la necesidad de crear, administrar y mantener los valores correctos para cada uno de los entornos en los que la aplicación será desplegada.
Los equipos de desarrollo solo necesitarán conocer en que ruta o con que nombre recibirán estos valores y no tendrán que preocuparse de desarrollar el acceso a un Key Vault, sea cual sea el que escojamos finalmente haciendo a la solución agnóstica de la infraestructura que tenemos detrás.
Esto nos facilita las tareas sobre todo cuando contamos con equipos de desarrollos externos o queremos evitar que los desarrolladores puedan acceder a las credenciales de los entornos productivos. Aunque para esto último tendremos que limitar los permisos sobre los elementos de producción en nuestro cluster/namespaces que los desarrolladores tienen.
En la siguiente entrega veremos cómo hacer que nuestros Ingress, utilicen los certificados que tenemos alojados en un Azure Key Vault.
¡Estate atento!
¡Sigue Aprendiendo!
Si quieres que te ayudemos a poner en marcha este tipo de proyecto, no dudes en contactar con nosotros. También puedes aprovechar las formaciones existentes para ampliar tus conocimientos 👇🏼
>> Más info
