La informática confidencial utiliza un entorno de ejecución de confianza (TEE) para proteger la memoria en uso, lo que garantiza el cifrado de los datos en reposo, en tránsito y en uso. Los contenedores confidenciales (CoCo) combinan el TEE con las implementaciones de Kubernetes. La implementación de un TEE en el pod permite aislar las cargas de trabajo de manera sólida, no solo de otras cargas en el clúster, sino también de los administradores de este.

El desafío de los contenedores confidenciales radica en dar los primeros pasos. Tomar la decisión de implementar un pod en estos contenedores implica solo cambiar una línea en el manifiesto. Sin embargo, para comenzar, debes implementar con éxito una serie de elementos juntos, idealmente en varios clústeres. Hace poco, Red Hat lanzó el soporte para los contenedores confidenciales en Microsoft Azure con la versión 1.9 del operador de contenedores en entornos de pruebas (sandbox) de Red Hat OpenShift y las versiones posteriores, además del soporte para la certificación remota con la compilación Trustee de Red Hat.

En este blog, se describe la manera en que se pueden usar los patrones validados para lograr tres objetivos:

1. comenzar a utilizar los CoCo de manera sencilla con el operador de contenedores en entornos de pruebas (sandbox) de OpenShift y la compilación Trustee de Red Hat en Azure;
2. proporcionar una base uniforme y declarativa para los CoCo que permita implementar las prácticas recomendadas;
3. demostrar la implementación de las aplicaciones con los CoCo.

Descripción de los patrones validados 

Los patrones validados son arquitecturas de código activo para diferentes casos prácticos de nube híbrida y multicloud. Cada uno se prueba y, una vez consolidado, se agrega al sistema de integración continua (CI) de Red Hat. Esto garantiza que realicemos pruebas con la última versión de los operadores, los lanzamientos de OpenShift y en varios entornos de nube pública.

Cada repositorio de patrones validados de Red Hat muestra un caso práctico empresarial como recursos de Kubernetes (charts de Helm, Kustomize y elementos básicos) que describen una stack de nube híbrida de forma declarativa e integral, desde los servicios hasta la infraestructura de respaldo. Los patrones validados facilitan las implementaciones complejas y altamente replicables. Además, son ideales para operar estas implementaciones a gran escala con las prácticas operativas de GitOps.

Motivos para utilizar patrones validados 

La implementación de soluciones empresariales complejas requiere varios pasos. Si cada uno se lleva a cabo de forma desorganizada, podrían generarse errores o ineficiencias. Para abordar este aspecto, los patrones validados ofrecen un proceso de implementación automatizado y validado con anterioridad:

• Utiliza un modelo de GitOps para representar el caso práctico como código.
• Sirve como un estudio de la viabilidad de los conceptos modificado para satisfacer una necesidad particular, y puedes convertirlo en una implementación real.
• Se puede replicar, por lo que es ideal para operar a gran escala.
• Los patrones validados permiten la colaboración. Cualquier persona puede sugerir mejoras, contribuir a ellos o utilizarlos porque todos los repositorios de Git son upstream.
• Cada patrón validado puede modificarse para que adaptarse a tus necesidades específicas. Si deseas intercambiar un elemento (por ejemplo, usar Ceph Storage en lugar de S3), solo tienes que comentar las secciones en la configuración e incluir otro repositorio.
• Está probado. Una vez que se validan los patrones, el caso práctico se incluye en el sistema de integración continua de Red Hat y se sigue probando en todas las versiones del producto mientras el patrón permanece activo.

Los patrones validados son una solución que incluye todos los recursos necesarios. Independientemente del marco que utilices al principio, tanto los elementos configurables como los básicos están listos para su uso. En este artículo, se utiliza un patrón validado para crear una forma sencilla de comenzar a utilizar los contenedores confidenciales.

Modo de implementación de un patrón

El sitio web de patrones validados tiene una extensa documentación sobre su uso. Las prácticas recomendadas requieren:

1. un repositorio de Git para el patrón, como una bifurcación, ya que los patrones validados utilizan GitOps, por lo que es necesario controlar el repositorio que se utiliza;
2. una computadora portátil para desarrolladores con oc, Git y Podman instalados;
3. un clúster de OpenShift vacío para la tarea de "gestión" del operador.

Así es la interacción de estos requisitos:

Con esta configuración, el patrón validado "posee" el contenido del clúster, lo que te permite comenzar con un solo lugar.

Uso de patrones validados para contenedores confidenciales

Los contenedores en entornos de pruebas (sandbox) de Red Hat OpenShift se basan en los contenedores de Kata y ofrecen la función adicional de ejecución de los contenedores confidenciales. Estos últimos se implementan en un enclave de hardware aislado y protegen los datos y el código de los usuarios con privilegios, como los administradores de nube o de clústeres. El proyecto CNCF Confidential Containers es la base de la solución de CoCo de OpenShift.

La informática confidencial permite proteger tus datos mientras están en uso al utilizar soluciones exclusivas basadas en el hardware. Con el hardware, puedes crear entornos aislados que sean de tu propiedad y proteger los datos de las cargas de trabajo del acceso no autorizado o los cambios mientras se ejecutan (cuando se están utilizando los datos).

Los CoCo posibilitan la informática confidencial desarrollada en la nube con varias plataformas de hardware y tecnologías de respaldo. Su objetivo es implementar un uso estandarizado de la informática confidencial en los pods y simplificar su uso en los entornos de Kubernetes. De este modo, los usuarios de Kubernetes pueden implementar las cargas de trabajo de CoCo con herramientas y flujos de trabajo conocidos, sin necesidad de tener un amplio conocimiento sobre las tecnologías básicas de la informática confidencial.

Para obtener más información, lee la publicación del blog Exploring the OpenShift confidencial containers solution. 

Arquitectura de los contenedores confidenciales 

La solución de contenedores confidenciales de Red Hat se basa en dos operadores clave:

• Contenedores confidenciales de Red Hat OpenShift: una función incorporada al operador de contenedores del entorno de pruebas (sandbox) de Red Hat OpenShift responsable de implementar los elementos básicos para conectar las cargas de trabajo (pods) y las máquinas virtuales confidenciales que se ejecutan en el TEE que proporciona el hardware.
• Certificación remota: la compilación Trustee de Red Hat se encarga de implementar y gestionar el servicio Key Broker Service (KBS) en un clúster de Red Hat OpenShift.

Para obtener más información, lee la publicación del blog Introducing Confidential Containers Trustee: Attestation Services Solution Overview and Use Cases.

Por lo general, los contenedores confidenciales tienen dos entornos: una zona de confianza y otra que no es de confianza. En estas zonas, se implementan Trustee y el operador del contenedor del entorno de pruebas (sandbox), respectivamente: 

Entonces, ¿cuál es el desafío? Para lograrlo, es necesario conocer la información específica sobre la infraestructura de nube o local. Es importante tener en cuenta varias preguntas, por ejemplo: ¿En qué región te encuentras? ¿Qué chipset (Intel, AMD, IBM Power, s390) e hipervisor tienes como objetivo? 

Para obtener más información sobre la implementación de CoCo, lee la publicación del blog Deployment Considerations for Red Hat OpenShift Confidential Containers Solution.

Introducción al patrón validado de contenedores confidenciales

El objetivo del patrón validado de contenedores confidenciales es facilitar los primeros pasos y comprender la forma de implementarlos. Utiliza la arquitectura de patrones validados para las siguientes tareas:

1. implementar los operadores necesarios para ejecutar los CoCo;
2. configurar los elementos periféricos, que incluyen los certificados (con Let's Encrypt, si es necesario);
3. extraer al usuario que implementa los CoCo en el clúster desde la nube con herramientas como Red Hat Advanced Cluster Manager;
4. implementar un conjunto de aplicaciones de ejemplo para demostrar varias funciones de los contenedores confidenciales, como la manipulación de estos.

Actualmente, el patrón se implementa en Microsoft Azure en un solo clúster con todos los elementos que provienen de un único patrón validado (se agregarán implementaciones adicionales en el futuro).

Funcionamiento

Utilizamos el operador de patrones validados para implementar Argo CD, y este ejecuta los operadores adicionales necesarios. 

El problema es que el mapa de configuración de pods pares, que incluye init-data y kata-policy, debe configurarse para Trustee Key Broker Service (KBS) de Trustee. Esta información es dinámica, por lo que el usuario debe utilizar la interfaz de línea de comandos (CLI) de Azure o acceder al portal de Azure. Desde el punto de vista de seguridad y control, init-data y kata-policy también plantean problemas, ya que se serializan en base64 antes de enviarse a un mapa de configuración, lo que dificulta que el usuario compruebe su estado.

 

Estos inconvenientes se resuelven utilizando metadatos insertados por el operador de patrones validados, lo que nos permite acceder fácilmente a la información sobre el clúster en nuestra aplicación. Las políticas avanzadas de Red Hat Advanced Cluster Manager se utilizan para recopilar la información que define el administrador de controladores de nube, así como para insertarla en los secretos y los mapas de configuración adecuados para el operador de contenedores en entornos de pruebas (sandbox).

Hashicorp Vault se utiliza como un sistema de gestión de claves (KMS) en el clúster con la configuración de secretos de patrones validados, lo que permite que los usuarios inicien Vault de manera uniforme desde un entorno de estación de trabajo para desarrolladores. Sirve para proporcionar secretos a Trustee, los cuales se sincronizan con el operador de secretos externos.

La combinación de estas funciones permite realizar la instalación con un solo comando, como se muestra a continuación: 

Requisitos 

Actualmente, solo podemos utilizar Azure como plataforma, y la topología de patrón simple es un solo clúster de OpenShift.

Los usuarios pueden implementar un clúster de Azure Red Hat OpenShift o uno autogestionado de OpenShift en Azure. El patrón incluye documentación sobre el uso de openshift-install para diseñar un clúster. El clúster y la cuenta de Azure deben tener acceso a las máquinas virtuales confidenciales de Azure en la región y disponibilidad de ellas. Hoy en día, el patrón utiliza las máquinas virtuales de clase DCasv5 para los contenedores confidenciales, pero esto se puede personalizar.

La única configuración adicional que se necesita para Azure es la implementación de una puerta de enlace de NAT para la subred del nodo de trabajo. Esto sucederá automáticamente.

En el caso de la estación de trabajo para desarrolladores, se requiere una estación POSIX (macOS o Linux) con oc y podman instalados.

Instrucciones detalladas

Solo hay que seguir tres pasos.

1. Crea una bifurcación

Primero, crea una bifurcación del repositorio de GitHub de patrones validados en tu empresa. Ten en cuenta que, debido a la uniformidad eventual de Argo CD, no es seguro utilizar directamente este repositorio.

git clone https://github.com/(TU EMPRESA}/coco-pattern.git

2. Genera claves aleatorias

Luego, genera los secretos de referencia. El patrón incluye scripts para producir claves aleatorias:

sh scripts/gen-secrets.sh

3. Realiza la instalación

Inicia sesión en el clúster con oc login y ejecuta la instalación del patrón:

./pattern.sh make install

Eso es todo. Espera a que el sistema se conecte y explora las aplicaciones implementadas.

Detalles de las aplicaciones implementadas

El patrón ejecuta una instancia de Argo CD denominada Simple ArgoCD en el menú de nueve casillas de la consola web de OpenShift. Se implementa una serie de aplicaciones. Las dos más importantes que deben tenerse en cuenta son hello-openshift y kbs-access.

La aplicación hello-openshift implementa una aplicación web tres veces: 

• como un pod estándar;
• como un pod de Kata, en el que la configuración del agente se anuló deliberadamente para permitir que un usuario ejecute comandos en el pod;
• como una aplicación "segura" con el refuerzo de los CoCo activado.

La aplicación kbs-access es una demostración sencilla sobre la recuperación de un secreto de Trustee mediante un contenedor init. KBS te permite acceder al secreto a través de su interfaz de programación de aplicaciones (API) web para que puedas visualizar la propagación de los cambios en el secreto por el sistema. Este método de contenedor init para recuperar los secretos es ideal para mejorar la seguridad de las aplicaciones actuales, ya que puedes hacerlo sin utilizar Trustee en cada lugar donde se desarrolle código.

Aspectos importantes de seguridad para la implementación de patrones de CoCo 

Los contenedores confidenciales se centran completamente en la seguridad, por lo que es importante tener en cuenta la estrategia del patrón validado de contenedores confidenciales. Hay dos aspectos principales para este patrón:

• En la actualidad, utiliza valores de referencia sencillos. Te recomendamos que obtengas más información sobre el flujo de certificación de RATS y que desarrolles políticas que se ajusten a tus necesidades de seguridad y al perfil de riesgo de los sistemas.
• Separa la implementación de Trustee. En relación con el primer punto, el servicio de certificación de Trustee se basa en el principio de que funciona en una zona de seguridad diferente y de confianza. Lo ideal es que sea un entorno diferente, como en las instalaciones o en el entorno de otro proveedor de nube.

En el siguiente diagrama, se muestra la arquitectura para implementar Trustee en un entorno separado con el patrón validado de contenedores confidenciales:

El futuro de los contenedores confidenciales 

El patrón validado de los CoCo es suficiente para comenzar. Su objetivo es que puedas operar correctamente en un solo clúster y entorno para que estés en condiciones de comenzar a realizar pruebas. En cambio, nuestro objetivo inmediato es ampliar este patrón con más ejemplos prácticos para que puedas extender el uso de contenedores confidenciales.

Queremos respaldar las implementaciones hub-and-spoke de varios clústeres, de manera que Trustee se implemente en el centro con Red Hat Advanced Cluster Management y que los clústeres spoke estén donde se ejecuten las cargas de trabajo confidenciales.

También queremos proporcionar ejemplos prácticos del uso de Trustee para la gestión de secretos. Hasta ahora, los ejemplos son sencillos. Nuestras prioridades para el desarrollo futuro son permitir el cifrado del almacenamiento gestionado en un TEE y la inicialización secreta de las aplicaciones que no reconocen Trustee ni la configuración VPN.

Además, queremos admitir otros entornos para la implementación de CoCo y Trustee, de manera que la confianza se pueda extender a los recursos en las instalaciones o en varios proveedores de servicios de nube.

Resumen 

El patrón validado de contenedores confidenciales proporciona un mecanismo sencillo para comenzar a utilizar los CoCo. Es ideal para realizar las primeras pruebas y bifurcaciones e implementar tus propias aplicaciones autónomas en un solo repositorio, gracias a la adopción del enfoque de aplicación de aplicaciones (app of apps) de GitOps de manera estandarizada con Argo CD. Como ya vimos, para comenzar, tan solo hay que ejecutar los comandos git clone y make install.