Procedimientos recomendados para la seguridad de pods en Azure Kubernetes Service (AKS)

A la hora de desarrollar y ejecutar aplicaciones en Azure Kubernetes Service (AKS), es importante tener en cuenta la seguridad de los pods. Las aplicaciones se deben diseñar con el principio del número mínimo de privilegios necesarios. Mantener seguros los datos privados es prioritario para los clientes. No deseará que credenciales como las cadenas de conexión de base de datos, las claves o los secretos y los certificados se vean expuestas al mundo exterior, donde un atacante podría aprovechar esos secretos con propósitos malintencionados. No debe incorporarlas al código ni insertarlas en las imágenes de contenedor. Este enfoque crearía un riesgo de exposición y limitaría la posibilidad de rotar esas credenciales, ya que las imágenes de contenedor se deberían volver a generar.

Este artículo de procedimientos recomendados se centra en cómo proteger los pods en AKS. Aprenderá a:

• Usar el contexto de seguridad del pod para limitar el acceso a los procesos y los servicios o una elevación de privilegios
• Autenticar con otros recursos de Azure mediante la identidad de carga de trabajo de Microsoft Entra
• Solicitar y recuperar credenciales de un almacén digital, como Azure Key Vault

También puede consultar los procedimientos recomendados sobre la seguridad del clúster y la administración de imágenes de contenedor.

Protección del acceso del pod a los recursos

Guía de procedimiento recomendado: para la ejecución como un usuario o grupo diferentes y limitar el acceso a los procesos y servicios del nodo subyacente, defina la configuración del contexto de seguridad del pod. Asigne el menor número de privilegios necesarios.

Para que las aplicaciones se ejecuten correctamente, los pods se deben ejecutar como un usuario o grupo definidos y no como root. El elemento securityContext de un pod o un contenedor permite definir valores de configuración como runAsUser o fsGroup para asumir los permisos adecuados. Asigne solo los permisos de usuario o grupo necesarios y no utilice el contexto de seguridad como un medio para asumir permisos adicionales. El runAsUser, elevación de privilegios y otros valores de configuración de las capacidades de Linux solo están disponibles en los pods y los nodos de Linux.

Cuando se ejecuta como un usuario que no es root, los contenedores no se pueden enlazar a los puertos con privilegios inferiores al 1024. En este escenario, los servicios de Kubernetes se pueden utilizar para ocultar el hecho de que una aplicación se ejecuta en un puerto determinado.

Un contexto de seguridad del pod también puede definir funcionalidades o permisos adicionales para el acceso a los procesos y servicios. Se pueden establecer las siguientes definiciones de contexto de seguridad comunes:

• allowPrivilegeEscalation define si el pod puede asumir privilegios de usuario root. Diseñe las aplicaciones de modo que este valor siempre esté establecido en false.
• Funcionalidades de Linux: permite el acceso del pod a los procesos de nodo subyacente. Tenga cuidado con la asignación de estas funcionalidades. Asigne el menor número de privilegios necesarios. Para más información, consulte las funcionalidades de Linux.
• Etiquetas SELinux es un módulo de seguridad del kernel de Linux que le permite definir directivas para el acceso a los servicios, los procesos y el sistema de archivos. De nuevo, asigne el menor número de privilegios necesarios. Para más información, consulte las opciones de SELinux disponibles en Kubernetes.

El siguiente ejemplo de manifiesto YAML de pod establece la configuración del contexto de seguridad para definir:

• El pod se ejecuta con el identificador de usuario 1000 y es parte del grupo con el identificador 2000
• No se pueden elevar los privilegios para usar root
• Permite a las funcionalidades de Linux acceder a las interfaces de red y al reloj en tiempo real del host (hardware)

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

Colabore con el operador del clúster para determinar la configuración de contexto de seguridad que necesita. Intente diseñar las aplicaciones para minimizar los permisos adicionales y el acceso que requiere el pod. Hay características de seguridad adicionales para limitar el acceso mediante AppArmor y seccomp (informática segura) que los operadores del clúster pueden implementar. Para más información, consulte Protección del acceso del contenedor a los recursos.

Limitación de la exposición de credenciales

Guía de procedimiento recomendado: no defina las credenciales en el código de aplicación. Use identidades administradas para los recursos de Azure para permitir que el pod solicite acceso a otros recursos. Se debería usar también un almacén digital, como Azure Key Vault, para almacenar y recuperar las credenciales y claves digitales. Las identidades administradas por pod están pensadas para usarse únicamente con pods de Linux e imágenes de contenedor.

Para limitar el riesgo de exposición de las credenciales en el código de la aplicación, evite el uso de credenciales compartidas o fijas. Las credenciales y las claves no se deberían incluir directamente en el código. Si se exponen estas credenciales, la aplicación se debe actualizar y volver a implementar. Un enfoque mejor es dar a los pods sus propias identidades y formas para autenticarse a sí mismos o recuperar automáticamente las credenciales de un almacén digital.

Usar una identidad de carga de trabajo de Microsoft Entra

Una identidad de carga de trabajo es una identidad utilizada por una aplicación que se ejecuta en un pod y que se puede autenticar en otros servicios de Azure que la admitan, como Storage o SQL. Se integra con las capacidades nativas de Kubernetes para federarse con proveedores de identidades externos. En este modelo de seguridad, el clúster de AKS actúa como emisor de tokens, Microsoft Entra ID usa OpenID Connect para detectar claves de firma pública y comprobar la autenticidad del token de cuenta de servicio antes de intercambiarlo por un token de Microsoft Entra. La carga de trabajo puede intercambiar un token de cuenta de servicio proyectado en su volumen por un token de Microsoft Entra que use la biblioteca cliente de Azure Identity mediante el SDK de Azure o la Biblioteca de autenticación de Microsoft (MSAL).

Para obtener más información sobre las identidades de carga de trabajo, consulte Configuración de un clúster de AKS para usar identidades de carga de trabajo de Microsoft Entra con las aplicaciones

Uso de Azure Key Vault con el controlador de CSI del almacén de secretos

El uso de la identidad de la carga de trabajo de Microsoft Entra permite la autenticación en los servicios compatibles de Azure. Para sus propios servicios o aplicaciones sin identidades administradas para recursos de Azure, puede seguir autenticándose mediante credenciales o claves. Se puede utilizar un almacén digital para almacenar el contenido de estos secretos.

Cuando las aplicaciones necesitan una credencial, se comunican con el almacén digital, recuperan el contenido de los secretos más reciente y luego se conectan al servicio solicitado. Azure Key Vault puede ser este almacén digital. El flujo de trabajo simplificado para recuperar una credencial de Azure Key Vault mediante identidades administradas de pods se muestra en el diagrama siguiente:

Con Key Vault, puede almacenar y rotar periódicamente secretos como credenciales, claves de cuenta de almacenamiento o certificados. Puede integrar Azure Key Vault con un clúster de AKS mediante el proveedor de Azure Key Vault para el controlador de CSI del almacén de secretos. El controlador de CSI del almacén de secretos permite que el clúster de AKS pueda recuperar de forma nativa el contenido de los secretos de Key Vault y proporcionárselo de forma segura solo al pod solicitante. Trabaje con el operador de clúster para implementar el controlador de CSI del almacén de secretos en los nodos de trabajo de AKS. Puede usar una identidad de carga de trabajo de Microsoft Entra para solicitar acceso a Key Vault y recuperar el contenido de los secretos que necesita mediante el controlador de CSI del almacén de secretos.

Pasos siguientes

Este artículo se centra en cómo proteger los pods. Para implementar algunas de estas áreas, consulte los artículos siguientes:

• Uso del Id. de carga de trabajo de Microsoft Entra para recursos de Azure con AKS
• Integración de Azure Key Vault con AKS