Espacios aislados de pods (versión preliminar) con Azure Kubernetes Service (AKS)

Para ayudar a proteger y asegurar las cargas de trabajo en contenedor frente a código que no es de confianza o potencialmente malintencionado, AKS ahora incluye un mecanismo denominado Espacios aislados de pods (versión preliminar). Espacios aislados de pods proporciona un límite de aislamiento entre, por un lado, la aplicación contenedora y, por otro, el kernel compartido y los recursos de proceso del host de contenedor. Por ejemplo, CPU, memoria y redes. Espacios aislados de pods complementa otras medidas de seguridad o controles de protección de datos con su arquitectura general para ayudarle a cumplir los requisitos normativos, del sector o de cumplimiento de gobernanza para proteger la información confidencial.

Este artículo le ayuda a comprender e implementar esta nueva característica.

Requisitos previos

• La CLI de Azure, versión 2.44.1 o posterior. Ejecute az --version para buscar la versión y ejecute az upgrade para actualizar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

• La versión 0.5.123 o posterior de la extensión de la CLI de Azure aks-preview.

• Registre la característica KataVMIsolationPreview en la suscripción de Azure.

• AKS admite Espacios aislados de pods (versión preliminar) en la versión 1.24.0 y posteriores con todos los complementos de red de AKS.

• Para administrar un clúster de Kubernetes, use kubectl, el cliente de línea de comandos de Kubernetes. Azure Cloud Shell viene con kubectl. Puede instalar kubectl localmente. Para ello debe usar el comando az aks install-cli.

Instalación de la versión preliminar de la extensión de la CLI de Azure en versión preliminar de AKS

Importante

Las características en versión preliminar de AKS están disponibles como opción de participación y autoservicio. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y garantía limitada. Las versiones preliminares de AKS reciben cobertura parcial del soporte al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

• Directivas de soporte técnico para AKS
• Preguntas más frecuentes de Soporte técnico de Azure

Ejecute el siguiente comando para instalar la extensión de versión preliminar de AKS:

az extension add --name aks-preview

Ejecute el siguiente comando para actualizar a la versión más reciente de la extensión publicada:

az extension update --name aks-preview

Registro de la marca de la característica KataVMIsolationPreview

Registre la marca de la característica KataVMIsolationPreview con el comando KataVMIsolationPreview, como se muestra en el siguiente ejemplo:

az feature register --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

Tarda unos minutos en que el estado muestre Registrado. Para comprobar el estado de registro se usa el comandoaz feature show:

az feature show --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

Cuando aparezca el estado Registrado, actualice el registro del proveedor de recursos Microsoft.ContainerService mediante el comando az provider register:

az provider register --namespace "Microsoft.ContainerService"

Limitaciones

A continuación se muestran restricciones con esta versión preliminar de Espacios aislados de pods (versión preliminar):

• Es posible que los contenedores Kata no alcancen los límites de rendimiento de IOPS que los contenedores tradicionales pueden alcanzar en Azure Files y SSD locales de alto rendimiento.

• Microsoft Defender para contenedores no admite la evaluación de pods en tiempo de ejecución de Kata.

• No se admite la red de host de Kata.

• AKS no admite controladores de Container Storage Interface y el controlador CSI del almacén de secretos en esta versión preliminar.

Cómo funciona

Para lograr esta funcionalidad en AKS, los contenedores de Kata que se ejecutan en el host de contenedor de Linux en Azure para la pila de AKS ofrecen aislamiento aplicado por hardware. Espacios aislados de pods amplía las ventajas del aislamiento de hardware, como un kernel independiente para cada pod de Kata. El aislamiento de hardware asigna recursos para cada pod y no los comparte con otros contenedores de Kata ni contenedores de espacio de nombres que se ejecutan en el mismo host.

La arquitectura de la solución se basa en los siguientes componentes:

• El host de contenedor de Linux en Azure para AKS
• Hipervisor de Microsoft Hyper-V
• Kernel de Linux Dom0 optimizado para Azure
• Virtual Machine Monitor (VMM) de Cloud-Hypervisor de código abierto
• Integración con el marco Kata Containers

La implementación de Espacios aislados de pods con Kata Containers es similar al flujo de trabajo en contenedores estándar para implementar contenedores. La implementación incluye opciones en tiempo de ejecución de Kata que puede definir en la plantilla de pods.

Para usar esta característica con un pod, la única diferencia es agregar runtimeClassName kata-mshv-vm-isolation a la especificación de pod.

Cuando un pod usa runtimeClass kata-mshv-vm-isolation, crea una VM para que actúe como espacio aislado del pod para hospedar los contenedores. La memoria predeterminada de la VM es de 2 GB, y la CPU predeterminada es un núcleo si el manifiesto de recursos de contenedor (containers[].resources.limits) no especifica un límite para la CPU y la memoria. Cuando se especifica un límite de CPU o memoria en el manifiesto de recursos de contenedor, la VM tiene containers[].resources.limits.cpu con el argumento 1 para usar una + xCPU, y containers[].resources.limits.memory con el argumento 2 para especificar 2 GB + yMemoria. Los contenedores solo pueden usar CPU y memoria hasta los límites de los contenedores. containers[].resources.requests se omite en esta versión preliminar mientras trabajamos para reducir la sobrecarga de CPU y memoria.

Implementación de un nuevo clúster

Siga los pasos siguientes para implementar clústeres de AKS en Linux en Azure con la CLI de Azure.

1. Cree un clúster de AKS mediante el comando az aks create y especifique los parámetros siguientes:

   • --workload-runtime: Especifique KataMshvVmIsolation para habilitar la característica de Espacios aislados de pods en el grupo de nodos. Con este parámetro, estos otros parámetros cumplirán los siguientes requisitos. De lo contrario, se produce un error en el comando e informa de un problema con los parámetros correspondientes.
   • --os-sku: AzureLinux. Solo os-sku de Linux en Azure admite esta característica en esta versión preliminar.
   • --node-vm-size: Cualquier tamaño de VM de Azure que sea una VM de 2.ª generación y admita trabajos de virtualización anidada. Por ejemplo, VM Dsv3.

   En el siguiente ejemplo se crea un clúster denominado myAKSCluster con un nodo en myResourceGroup:

   az aks create 
       --name myAKSCluster \
       --resource-group myResourceGroup \
       --os-sku AzureLinux \
       --workload-runtime KataMshvVmIsolation \
       --node-vm-size Standard_D4s_v3 \
       --node-count 1 \
       --generate-ssh-keys
   

2. Ejecute el siguiente comando para obtener las credenciales de acceso del clúster de Kubernetes. Use el comando az aks get-credentials y reemplace los valores del nombre del clúster y el nombre del grupo de recursos.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
   

3. Enumere todos los pods de todos los espacios de nombres mediante el comando kubectl get pods.

   kubectl get pods --all-namespaces
   

Implementación en un clúster existente

Para usar esta característica con un clúster de AKS existente, se deben cumplir los siguientes requisitos:

• Siga los pasos para registrar la marca de la característica KataVMIsolationPreview.
• Compruebe que el clúster ejecute Kubernetes, versión 1.24.0 o posterior.

Use el siguiente comando para habilitar Espacios aislados de pods (versión preliminar) mediante la creación de un grupo de nodos para hospedarlo.

1. Agregue un grupo de nodos al clúster de AKS mediante el comando az aks nodepool add. Especifique los parámetros siguientes:

   • --resource-group: Escriba el nombre de un grupo de recursos existente en el que va a crear el clúster de AKS.
   • --cluster-name: Escriba un nombre único para el clúster de AKS, como myAKSCluster.
   • --name: Escriba un nombre único para el grupo de nodos de clústeres, como nodepool2.
   • --workload-runtime: Especifique KataMshvVmIsolation para habilitar la característica de Espacios aislados de pods en el grupo de nodos. Junto con el parámetro --workload-runtime, estos otros parámetros cumplirán los siguientes requisitos. De lo contrario, se produce un error en el comando e informa de un problema con los parámetros correspondientes.
     • --os-sku: AzureLinux. Solo os-sku de Linux en Azure admite esta característica en la versión preliminar.
     • --node-vm-size: Cualquier tamaño de VM de Azure que sea una VM de 2.ª generación y admita trabajos de virtualización anidada. Por ejemplo, VM Dsv3.

   En el ejemplo siguiente se agrega un grupo de nodos a myAKSCluster con un nodo en nodepool2 en myResourceGroup:

   az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3
   

2. Ejecute el comando az aks update para habilitar Espacios aislados de pods (versión preliminar) en el clúster.

   az aks update --name myAKSCluster --resource-group myResourceGroup
   

Implementación de una aplicación de confianza

Para demostrar la implementación de una aplicación de confianza en el kernel compartido en el clúster de AKS, realice los pasos siguientes.

1. Cree un archivo denominado trusted-app.yaml para describir un pod de confianza y, a continuación, pegue el manifiesto siguiente.

   kind: Pod
   apiVersion: v1
   metadata:
     name: trusted
   spec:
     containers:
     - name: trusted
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
   

2. Implemente el pod de Kubernetes ejecutando el comando kubectl apply y especifique el archivo trusted-app.yaml:

   kubectl apply -f trusted-app.yaml
   

   La salida del comando es similar al ejemplo siguiente:

   pod/trusted created
   

Implementación de una aplicación que no es de confianza

Para demostrar la implementación de una aplicación que no es de confianza en el espacio aislado del pod en el clúster de AKS, realice los pasos siguientes.

1. Cree un archivo denominado untrusted-app.yaml para describir un pod que no es de confianza y, a continuación, pegue el manifiesto siguiente.

   kind: Pod
   apiVersion: v1
   metadata:
     name: untrusted
   spec:
     runtimeClassName: kata-mshv-vm-isolation
     containers:
     - name: untrusted
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
   

   El valor de runtimeClassNameSpec es kata-mhsv-vm-isolation.

2. Implemente el pod de Kubernetes ejecutando el comando kubectl apply y especifique el archivo untrusted-app.yaml:

   kubectl apply -f untrusted-app.yaml
   

   La salida del comando es similar al ejemplo siguiente:

   pod/untrusted created
   

Comprobación de la configuración del aislamiento del kernel

1. Para acceder a un contenedor dentro del clúster de AKS, inicie una sesión de shell con el comando kubectl exec. En este ejemplo, va a acceder al contenedor dentro del pod que no es de confianza.

   kubectl exec -it untrusted -- /bin/bash
   

   Kubectl se conecta al clúster, ejecuta /bin/sh dentro del primer contenedor dentro del pod que no es de confianza y reenvía los flujos de entrada y salida del terminal al proceso del contenedor. También puede iniciar una sesión de shell en el contenedor que hospeda el pod de confianza.

2. Después de iniciar una sesión de shell en el contenedor del pod que no es de confianza, puede ejecutar comandos para comprobar que el contenedor que no es de confianza se ejecuta en un espacio aislado del pod. Verá que tiene una versión de kernel diferente en comparación con el contenedor de confianza fuera del espacio aislado.

   Para ver la versión del kernel, ejecute el comando siguiente:

   uname -r
   

   El ejemplo siguiente es similar a la salida del kernel del espacio aislado del pod:

   root@untrusted:/# uname -r
   5.15.48.1-8.cm2
   

3. Inicie una sesión de shell en el contenedor del pod de confianza para comprobar la salida del kernel:

   kubectl exec -it trusted -- /bin/bash
   

   Para ver la versión del kernel, ejecute el comando siguiente:

   uname -r
   

   El ejemplo siguiente se parece a la salida de la VM que ejecuta el pod de confianza, que es un kernel diferente al pod que no es de confianza que se ejecuta en el espacio aislado del pod:

   5.15.80.mshv2-hvl1.m2
   

Limpieza

Cuando haya terminado de evaluar esta característica, para evitar cargos de Azure, limpie los recursos innecesarios. Si ha implementado un nuevo clúster como parte de la evaluación o prueba, puede eliminar el clúster con el comando az aks delete.

az aks delete --resource-group myResourceGroup --name myAKSCluster

Si ha habilitado Espacios aislados de pod (versión preliminar) en un clúster existente, puede quitar los pods mediante el comando kubectl delete pod.

kubectl delete pod pod-name

Pasos siguientes

Obtenga más información sobre los hosts dedicados de Azure para los nodos con el clúster de AKS para usar el aislamiento de hardware y el control sobre los eventos de mantenimiento iniciados por la plataforma Azure.