Compartir a través de

Contenedores confidenciales (versión preliminar) en Azure Kubernetes Service (AKS)

  • Artículo

Los contenedores confidenciales proporcionan un conjunto de características y funcionalidades para proteger aún más las cargas de trabajo de contenedor estándar para lograr mayores objetivos de seguridad y privacidad de los datos e integridad del código del entorno de ejecución. Azure Kubernetes Service (AKS) incluye Contenedores confidenciales (versión preliminar) en AKS.

Los contenedores confidenciales se basan en contenedores confidenciales Kata y cifrado basado en hardware para cifrar la memoria del contenedor. Establece un nuevo nivel de confidencialidad de los datos evitando que los datos de la memoria durante el cálculo estén en formato de texto no cifrado y legible. La confianza se obtiene en el contenedor a través de la atestación de hardware, lo que permite el acceso a los datos cifrados por entidades de confianza.

Junto con Espacio seguro de pod, es posible ejecutar cargas de trabajo confidenciales aisladas en Azure para proteger los datos y las cargas de trabajo. Razones que hacen que un contenedor sea confidencial:

  • Transparencia: el entorno de contenedor confidencial donde se comparte la aplicación confidencial, puede ver y comprobar si es seguro. Todos los componentes de Base informática de confianza (TCB) deben ser de código abierto.
  • Capacidad de auditoría: tendrá la capacidad de comprobar y ver qué versión del paquete de entorno de CoCo incluye el sistema operativo invitado Linux y si todos los componentes están actualizados. Microsoft inicia sesión en el sistema operativo invitado y el entorno de tiempo de ejecución del contenedor para realizar comprobaciones mediante atestación. También publica un algoritmo hash seguro (SHA) de compilaciones de sistema operativo invitado para crear una historia de capacidad de auditoría y control de cadenas.
  • Atestación completa: todo lo que forme parte del TEE se medirá completamente mediante la CPU con la capacidad de comprobación remota. El informe de hardware del procesador AMD SEV-SNP reflejará las capas de contenedor y el hash de configuración del entorno de ejecución del contenedor mediante las notificaciones de atestación. La aplicación puede capturar el informe de hardware localmente, incluido el informe que refleja la imagen del sistema operativo invitado y el entorno de ejecución del contenedor.
  • Integridad del código: el cumplimiento en tiempo de ejecución siempre está disponible mediante directivas definidas por el cliente para contenedores y configuración de contenedores, como directivas inmutables y firma de contenedores.
  • Aislamiento del operador: diseños de seguridad que asumen privilegios mínimos y blindaje de aislamiento más alto de todas las partes que no son de confianza, incluidos los administradores de clientes o inquilinos. Incluye la protección del acceso del plano de control de Kubernetes existente (kubelet) a pods confidenciales.

Con otras medidas de seguridad o controles de protección de datos como parte de su arquitectura general, estas funcionalidades ayudan a cumplir los requisitos normativos, del sector o de cumplimiento de gobernanza para proteger la información confidencial.

Este artículo ayuda a comprender la característica Contenedores confidenciales y a implementar y configurar lo siguiente:

  • Implementar o actualizar un clúster de AKS con la CLI de Azure
  • Agregar una anotación al pod YAML para marcar el pod como que se ejecuta como un contenedor confidencial
  • Agregar una directiva de seguridad al pod de YAML
  • Implementar la aplicación en computación confidencial

Escenarios admitidos

Los contenedores confidenciales (versión preliminar) son adecuados para escenarios de implementación que implican datos confidenciales. Por ejemplo, información de identificación personal (PII) o cualquier dato con seguridad sólida necesaria para el cumplimiento normativo. Algunos escenarios comunes con contenedores son:

  • Ejecute análisis de macrodatos mediante Apache Spark para el reconocimiento de patrones de fraude en el sector financiero.
  • Ejecutar ejecutores de GitHub autohospedados para firmar código de forma segura como parte de las prácticas de DevOps de integración continua e implementación continua (CI/CD).
  • Inferencia y entrenamiento de machine Learning de modelos de MACHINE Learning mediante un conjunto de datos cifrado de un origen de confianza. Solo se descifra dentro de un entorno de contenedor confidencial para conservar la privacidad.
  • Creación de salas limpias de macrodatos para la coincidencia de identificadores como parte del cálculo de varias partes en sectores como el comercio minorista con publicidad digital.
  • Creación de zonas de aterrizaje de confianza cero de computación confidencial para cumplir las normativas de privacidad de las migraciones de aplicaciones a la nube.

Consideraciones

A continuación se indican consideraciones sobre esta versión preliminar de Contenedores confidenciales:

  • Aumento del tiempo de inicio del pod en comparación con los pods runc y los pods aislados del kernel.
  • No se admiten imágenes de contenedor de la versión 1.
  • Los contenedores efímeros y otros métodos de solución de problemas, como exec en un contenedor, salidas de registro de contenedores y stdio requieren una modificación y reimplementación de directivas para habilitar ExecProcessRequest, ReadStreamRequest, WriteStreamRequest y CloseStdinRequest.
  • Debido a las medidas de capa de imagen de contenedor que se codifican en la directiva de seguridad, no se recomienda usar la etiqueta latest al especificar contenedores.
  • Los servicios, equilibradores de carga y EndpointSlices solo admiten el protocolo TCP.
  • El generador de directivas solo admite pods que usan direcciones IPv4.
  • Las variables de entorno de pods basadas en archivos configmap y secretos no se pueden cambiar después de implementar el pod.
  • No se admiten los registros de terminación del pod. Aunque los pods escriben registros de terminación en /dev/termination-log o en una ubicación personalizada si se especifican en el manifiesto del pod, el host o kubelet no puede leer esos registros. Los cambios del pod a ese archivo no se reflejan en el host.

Información general de la asignación de recursos

Es importante que comprenda el comportamiento de asignación de recursos de memoria y procesador en esta versión.

  • CPU: la corrección de compatibilidad asigna una vCPU al sistema operativo base dentro del pod. Si no se especifica ningún recurso limits, las cargas de trabajo no tienen asignados recursos compartidos de CPU independientes, la vCPU se comparte con esa carga de trabajo. Si se especifican límites de CPU, los recursos compartidos de CPU se asignan explícitamente para cargas de trabajo.
  • Memoria: el controlador Kata-CC usa 2 GB de memoria para la memoria UVM OS y X MB de memoria adicional donde X es el limits de recursos si se especifica (lo que da lugar a una máquina virtual de 2 GB cuando no se da ningún límite, sin memoria implícita para contenedores). El controlador de Kata usa 256 MB de memoria base para el UVM OS y X MB de memoria adicional cuando se especifican los limits de recursos en el manifiesto YAML. Si no se especifican límites, se agrega un límite implícito de 1792 MB, lo que da como resultado una máquina virtual de 2 GB y 1792 MB de memoria implícita para contenedores.

En esta versión, no se admite la especificación de solicitudes de recursos en los manifiestos de pod. containerd no pasa las solicitudes a Kata Shim y, como resultado, no se implementa la reserva de recursos en función de las solicitudes de recursos del manifiesto de pod. Use limits de recursos en lugar de requests de recursos para asignar recursos de memoria o CPU para cargas de trabajo o contenedores.

Con el sistema de archivos de contenedor local respaldado por la memoria de máquina virtual, escribir en el sistema de archivos de contenedor (incluido el registro) puede rellenar la memoria disponible proporcionada al pod. Esta condición puede dar lugar a posibles bloqueos de pod.

Pasos siguientes