Unidad 6.4: Registro de contenedores y selección de plataforma

Introducción

Cada plataforma de contenedores necesita un lugar de confianza para almacenar imágenes y una historia defendible sobre quién puede subir y descargarlas. En IONOS, el Registro de Contenedores le proporciona ese almacenamiento, pero gobierna el acceso de una manera que sorprenderá a un arquitecto que espera el modelo basado en roles común en los registros de los proveedores de servicios en la nube: el acceso es solo mediante token, y la disciplina que se aplica a esos tokens es la totalidad de su gobernanza de acceso. Esta unidad establece primero ese modelo de gobernanza y la decisión de selección de plataforma detrás de cualquier estado de contenedores, y termina construyendo un registro, definiendo el alcance de un token y conectando un cliente en el Data Center Designer.

FinCorp, nuestra fintech regulada alemana, está configurando una tubería CI/CD para enviar sus nuevos servicios adjuntos a la inteligencia artificial hacia Managed Kubernetes. El registro se encuentra entre la granja de compilación y el Cluster, por lo que el modelo de acceso que impone se convierte en un control de gobernanza que los auditores de FinCorp examinarán. La pregunta de selección de plataforma se ejecuta en paralelo: FinCorp debe decidir si Managed Kubernetes lleva sus cargas de trabajo de contenedores o si se justifica una distribución implementada por el cliente, y esa decisión depende por completo de quién esté dispuesto a poseer el ciclo de vida del plano de control.

1. Acceso solo con tokens y gobernanza mediante disciplina de tokens

El Registro de Contenedores no tiene control de acceso basado en roles. No hay roles, no hay usuarios asignados a permisos dentro del registro, y no hay lenguaje de política. El acceso se concede exclusivamente a través de tokens de acceso al registro, por lo que la postura de seguridad del registro es precisamente la disciplina que se impone a esos tokens. Un arquitecto que proviene de un registro con RBAC debe internalizar esta inversión: no asigna un principal a un rol, crea una credencial y la limita.

Un token lleva un alcance construido a partir de tres partes. El Tipo es either Registry, que permite al token listar los repositorios en el registro, o Repository, que permite al token gestionar el contenido de uno o más repositorios con nombre. El Path nombra los repositorios a los que el token accede, donde * es un comodín que otorga acceso a todos los repositorios. La Acción es una o más de Pull, Push, y Admin, donde Admin permite al token eliminar artefactos. Un token con capacidad de push también debe llevar pull: cuando selecciona Push, también debe establecer Pull. No hay lista de control de acceso por repositorio más allá de esta limitación de token; el registro no ofrece ACL más finas en un solo repositorio que el modelo de token expresa.

Los tokens vienen en dos tipos: un token de acceso al registro permanente y un token temporal que lleva una fecha de caducidad. La caducidad mínima que puede establecer en un token temporal es de una hora. El secreto de un token se muestra exactamente una vez en la creación; si lo pierde, no puede recuperarlo, solo reemplazar el token. Un token tiene tres estados de ciclo de vida: enabled, disabled, y deleted. Puede deshabilitar un token para suspenderlo, pero el hecho de seguridad relevante es lo que sucede en la caducidad: un token caducado se elimina, no solo se deshabilita. Esto significa que una caducidad es un fin de vida duro para la credencial, y no hay acceso anónimo ni nivel de extracción pública al que recurrir. La extracción, al igual que la inserción, siempre requiere un token válido.

Debido a que el registro solo le da tokens, la gobernanza es la disciplina de tokens, y la disciplina es concreta. Emite un token por cada etapa de la canalización en lugar de una credencial compartida: la etapa de compilación que inserta imágenes obtiene un token de push y pull limitado a los repositorios que produce, mientras que la etapa de implementación que extrae imágenes en el Cluster obtiene un token solo de extracción. Limite cada token lo más estrechamente que permita la etapa, prefiriendo un token de tipo Repository en una ruta con nombre sobre un comodín. Establezca una caducidad que coincida con la vida útil prevista de la credencial y rote por acuñar un reemplazo antes de que el antiguo caduque, ya que la caducidad elimina el token directamente y una canalización no rotada simplemente se detiene. Mantenga estos tokens fuera de las credenciales personales por completo; el modelo de token existe precisamente para que CI/CD nunca se autentique como una persona. Para FinCorp, esto se mapa limpiamente en las expectativas de sus auditores: cada etapa de la canalización tiene una credencial distinta, limitada y con caducidad, y la ausencia de secretos compartidos de larga duración es demostrable desde la lista de tokens.

El registro está cifrado en REST y publica un SLA de disponibilidad del 99,95% por servicio. Actualmente está disponible en la ubicación de Frankfurt (DE/FRA), y tanto el nombre del registro como su ubicación son inmutables después de la creación, por lo que la ubicación es una decisión de colocación que se toma una vez. El nombre del registro también debe ser globalmente único en todos los clientes, contener solo caracteres alfanuméricos y guiones, tener entre 3 y 63 caracteres, comenzar con una letra a-z y terminar con un carácter alfanumérico.

2. Análisis de vulnerabilidades como un interruptor de un solo sentido

El análisis de vulnerabilidades es una función adicional que analiza el software en sus imágenes de contenedor contra vulnerabilidades y exposiciones comunes conocidas (CVE). Un análisis se ejecuta cada vez que se publica un artefacto y nuevamente cuando se publican nuevas definiciones de vulnerabilidades, por lo que la cobertura sigue tanto el cambio de imagen como el catálogo de CVE en evolución, con una ventana de reanálisis de 30 días. Los resultados dan detalles de CVE por artefacto que puede conectar a una CI/CD, que es el valor para una tienda regulada como FinCorp que debe demostrar la debida diligencia en su cadena de suministro.

El detalle arquitectónico que importa es la irreversibilidad. Una vez que se habilita el análisis de vulnerabilidades en un registro, no se puede deshabilitar más tarde. Habilitar es, por lo tanto, una decisión deliberada y de un solo sentido, no una configuración para activar para una prueba y desactivar después. Trátelo como una propiedad a la que se compromete por la vida del registro, y decida conscientemente al crearlo o después, en lugar de descubrir la restricción cuando intente revertirla. Para FinCorp, la decisión es sencilla, el análisis de vulnerabilidades permanece activado, pero el arquitecto aún debe registrarla como un compromiso irreversible.

3. Selección de plataforma: quién lleva el ciclo de vida del plano de control

La decisión de la plataforma de contenedores en IONOS se centra fundamentalmente en quién posee el plano de control de Kubernetes y su carga de cumplimiento, no en la paridad de características entre distribuciones. Tres opciones se encuentran en el mismo sustrato de cómputo y almacenamiento de IONOS, pero difieren notablemente en su modelo operativo.

La siguiente tabla resume las tres opciones y dónde recae el ciclo de vida y la carga de cumplimiento.

Managed Kubernetes es el valor predeterminado. IONOS opera el plano de control y lo proporciona de forma gratuita, mientras que usted solo paga por el Node Pools. El ciclo de vida del plano de control, sus actualizaciones, su disponibilidad, es responsabilidad de IONOS bajo un SLA del 99,95% por servicio. En cuanto al cumplimiento, Managed Kubernetes se encuentra dentro del ámbito de certificación de BSI IT-Grundschutz (ISO 27001) en centros de datos alemanes, pero no está dentro del ámbito de acreditación de BSI C5. Esta es la precisión de cumplimiento por servicio que exige la plataforma: no se puede decir "el Cluster es C5", porque la acreditación de tipo 1 de C5 (otorgada el 2023-11-07) cubre Compute Engine, Cloud Cubes y S3 Object Storage, pero no Managed Kubernetes.

Red Hat OpenShift no es un servicio administrado de IONOS. IONOS no ofrece una solución de OpenShift administrada y no vende ni factura suscripciones de OpenShift. En su lugar, IONOS y Red Hat han validado conjuntamente OpenShift en ejecución en la infraestructura de IONOS, produciendo una implementación de referencia para los socios de CCSP de Red Hat. El cliente (el socio de CCSP) implementa y administra sus propios clústeres y, por lo tanto, posee todo el ciclo de vida del plano de control. La licencia es de tipo "traiga su propia licencia", con suscripciones obtenidas de Red Hat o un distribuidor individual; los recursos subyacentes de IONOS se facturan al precio de lista regular sin recargo específico de OpenShift. Antes de ejecutar OpenShift en producción, los socios deben programar una validación de Red Hat a través de un representante de IONOS Cloud, quien coordina la revisión que confirma que la implementación cumple con los requisitos de producción de Red Hat. Elija este camino solo cuando la plataforma OpenShift en sí sea un requisito estricto y esté preparado para poseer su operación.

SUSE Rancher Prime sigue un modelo de implementación autogestionada en IONOS. IONOS no proporciona Rancher Prime como un servicio administrado: el cliente es responsable del ciclo de vida completo del entorno de Rancher Prime, incluida la instalación, escalado y mantenimiento continuo del servidor de administración, así como la configuración y administración de los paisajes de Cluster descendentes. El modelo comercial es de tipo "traiga su propia suscripción", donde IONOS factura la infraestructura (Compute Engine, Block Storage, redes) a tarifas estándar y SUSE (o el distribuidor de SUSE del cliente) factura las licencias de Rancher Prime y SUSE Linux Enterprise Server, sin tarifas de integración ocultas de IONOS. La asociación está orientada a la gestión soberana de Kubernetes en la región DACH, con alineaciones con BSI IT-Grundschutz, NIS2, requisitos de la UE GDPR y requisitos de la cadena de suministro de la UE; la salvedad operativa es que usted, no IONOS, ejecuta el plano de administración. La descripción anterior de Rancher Prime como un servicio administrado de SUSE no es válida: SUSE suministra la suscripción y el soporte, pero el cliente opera la plataforma.

El resumen honesto para FinCorp: las opciones implementadas por el cliente intercambian la comodidad de un plano de control administrado por capacidades específicas de la distribución, y al hacerlo, transfieren el ciclo de vida del plano de control y la mayor parte de la carga de cumplimiento a los propios equipos de FinCorp. A menos que OpenShift o Rancher sea un requisito declarado, Managed Kubernetes es la opción con menor carga, respaldada por IONOS, que ya se encuentra dentro del ámbito de IT-Grundschutz.

Un límite que se aplica a las tres: donde las acreditaciones y certificaciones cubren la capa de infraestructura de IONOS, cubren solo esa capa, no las cargas de trabajo del cliente que se ejecutan en el Cluster. Un Cluster que se encuentra en infraestructura acreditada no hace que la aplicación en él sea cumplida; la cumplimiento de Workload sigue siendo responsabilidad del cliente, independientemente de qué distribución ejecute el plano de control.

3.1 Multi-Cluster versus aislamiento de espacio de nombres

Dentro de cualquier plataforma que elija, separar las cargas de trabajo es una decisión de dos niveles. El aislamiento de espacio de nombres divide un solo Cluster lógicamente: los inquilinos comparten el mismo plano de control y Node Pools, y se aplica la separación con políticas de red y cuotas de recursos dentro de Cluster. Es la opción más barata y densa, y es la opción predeterminada para entornos que comparten un límite de confianza y cumplimiento, por ejemplo, varios equipos de desarrollo internos de FinCorp.

El aislamiento de multi-Cluster coloca las cargas de trabajo en clústeres separados, dando a cada uno su propio plano de control y un límite de radio de explosión duro. Es la separación más fuerte y la que debe alcanzar cuando las cargas de trabajo se encuentran en diferentes ámbitos de cumplimiento, cuando un vecino ruidoso o hostil es inaceptable, o cuando una actualización o falla no debe poder cruzar entre inquilinos. En Managed Kubernetes, el costo de elegir el aislamiento de multi-Cluster está limitado por una cuota de Cluster por contrato (un valor predeterminado que se puede aumentar a petición a través del soporte de IONOS Cloud), por lo que un patrimonio que necesite muchos inquilinos aislados con dureza debe planificar alrededor de ese techo, potencialmente dividiéndolos entre contratos (el contrato siendo el límite de gobernanza establecido en el Módulo 2). El patrón de FinCorp es mantener su Workload de producción regulado en su propio Cluster, aislado del Cluster de desarrollo compartido, precisamente para que el ámbito de cumplimiento de producción no se entrelace con el desarrollo.

DCD Implementación paso a paso

Usted creará un Registro de Contenedores, habilitará el análisis de vulnerabilidades, creará un token con un alcance limitado y autenticará un cliente de Docker contra él. Esto realiza el modelo de acceso de la Sección 1: un registro único cuya única superficie de acceso es un conjunto de tokens con alcance limitado y expiración, listo para respaldar la canalización de FinCorp. El único requisito previo es un usuario de contrato con permiso para crear el registro.

Objetivo de construcción: Crear un registro, emitir un token con alcance limitado, autenticar un cliente.

Pasos (en el Data Center Designer):

1. Vaya a Menú > Contenedores > Registro de Contenedores para abrir el Administrador de Registro de Contenedores.
2. Haga clic en Agregar un registro. Proporciona un Nombre. Recuerde que el nombre es permanente, único globalmente en todos los clientes, alfanumérico y guiones, de 3 a 63 caracteres, que comienza con una letra y termina alfanuméricamente.
3. Elija la Ubicación desde el menú desplegable. Esto también es inmutable después de la creación, y el registro está disponible en la ubicación de Frankfurt (DE/FRA). Decida deliberadamente.
4. Configure opcionalmente el Programa de recolección de basura, seleccionando el día(s) y hora (UTC) para la ejecución semanal que libera el almacenamiento ocupado por capas de imagen no referenciadas. La recolección de basura está deshabilitada de forma predeterminada; tenga en cuenta que el registro es de solo lectura mientras se ejecuta, así que coloque la ventana fuera de las horas pico.
5. Decida sobre el Análisis de vulnerabilidades. Puede habilitarlo aquí, pero una vez habilitado no se puede deshabilitar más adelante, así que trate la habilitación como un compromiso de un solo sentido. (También puede agregarlo a un registro existente después a través de la sección Propiedades del registro, donde se aplica la misma irreversibilidad).
6. Haga clic en Agregar registro. El registro y su almacenamiento se crean; está listo para usarse cuando su estado alcanza En ejecución. El nombre de host del registro se asigna solo una vez que alcanza el estado En ejecución.
7. Seleccione el registro en ejecución y abra la pestaña Tokens, luego haga clic en Agregar token. Asigne un Nombre al token (que también no se puede cambiar más adelante).
8. Defina el alcance del token: establezca el Tipo (Registry para enumerar repositorios, o Repository para administrar el contenido del repositorio), ingrese la Ruta de los repositorios a los que accede (evite el comodín * a menos que la etapa realmente necesite todos los repositorios), y seleccione la Acción(iones). Para un token de empuje de etapa de compilación, seleccione Empuje y, porque empujar requiere, también Extraer. Para una expiración opcional, establezca una fecha de expiración que no sea inferior a una hora. Guarde el token y copie su secreto ahora: se muestra solo una vez.
9. Autentique un cliente. Utilizando la CLI de Docker, inicie sesión en el nombre de host del registro con el token como credencial:

docker login {registry-name}.cr.de-fra.ionos.com
## Username and Password: supply the token credentials (not a personal login)

El cliente ahora puede realizar operaciones de push y pull dentro del alcance del token. El punto arquitectónico es que esta es la única ruta de autenticación: no existe una operación de pull anónima, por lo que incluso el acceso de lectura se realiza a través de un token con alcance.

Errores comunes:

• Tratar el escaneo de vulnerabilidades como reversible. Es un interruptor de un solo sentido; una vez habilitado, no se puede desactivar. Decida antes de habilitarlo.
• Esperar desactivar un token caducado. La caducidad elimina el token, no lo desactiva, por lo que una credencial de tubería no rotada desaparece y la tubería se rompe. Rotule creando un reemplazo antes de la caducidad.
• Intentar recuperar un secreto de token perdido. El secreto se muestra exactamente una vez durante la creación; si se pierde, debe crear un nuevo token.
• Otorgar Push sin Pull. Un token con capacidad de push también debe llevar pull, o el push falla.
• Recurrir a un comodín * o a un solo token compartido en todas las etapas. Emite un token con alcance limitado por cada etapa de la tubería; el registro no tiene RBAC, por lo que el alcance del token es su único control de acceso.
• Suponer que puede cambiar el nombre o la ubicación del registro más tarde. Tanto el nombre como la ubicación son inmutables; elegir la ubicación incorrecta significa recrear el registro.
• Confíar en un nivel de extracción pública para imágenes base. No existe acceso anónimo y no hay nivel de extracción pública; cada extracción necesita un token.

Resumen

El Registro de Contenedores de IONOS gobierna el acceso a través de tokens con ámbito y caducidad, en lugar de control de acceso basado en roles, por lo que la seguridad del registro es exactamente la disciplina que se aplica a sus tokens: uno por fase de pipeline, con ámbito limitado, caducidad, rotación por reemplazo y mantenimiento fuera de las credenciales personales. El análisis de vulnerabilidades es un complemento valioso pero irreversible, y el nombre y la ubicación del registro son permanentes. La decisión de selección de plataforma depende de quién posee el ciclo de vida del control de plano y la carga de cumplimiento: Managed Kubernetes mantiene ambos con IONOS dentro del ámbito de IT-Grundschutz, mientras que OpenShift y Rancher Prime se despliegan en el cliente y transfieren esa propiedad a usted. Separe las cargas de trabajo con espacios de nombres cuando compartan un límite de confianza y con varios clusters cuando necesiten uno duro, dentro del límite por contrato de Cluster.

Puntos clave:

• El Registro de Contenedores no tiene RBAC; el acceso es solo mediante tokens, sin acceso anónimo y sin nivel de extracción pública. La gobernanza es la disciplina del token.
• El ámbito del token es Tipo (Registro o Repositorio) más Ruta más Acción (Extraer/Enviar/Administrar); Enviar requiere Extraer, y el secreto del token se muestra solo una vez.
• Los tokens se eliminan al caducar, no se deshabilitan; rotúlelos emitiendo un reemplazo antes de la caducidad. El tiempo mínimo de caducidad es de una hora.
• El análisis de vulnerabilidades es un interruptor de un solo sentido: una vez habilitado, no se puede deshabilitar. El nombre y la ubicación del registro son inmutables.
• Managed Kubernetes mantiene el ciclo de vida del control de plano y el cumplimiento con IONOS (IT-Grundschutz, no C5); OpenShift (CCSP, BYOL) y Rancher Prime (autogestionado, BYOS) se despliegan en el cliente, transfiriendo esa carga a usted.
• Las attestaciones cubren solo la capa de infraestructura de IONOS, nunca las cargas de trabajo del cliente en el Cluster.
• Utilice espacios de nombres para separación de límites compartidos y varios clusters para separación dura, dentro de su cuota por contrato de Cluster (aumente según sea necesario).

Terminología importante:

• Token de acceso al registro: la única credencial de acceso para el Registro de Contenedores, con ámbito definido por tipo, ruta y acción; permanente o temporal (con una caducidad que lo elimina al final de su vida).
• Análisis de vulnerabilidades: un complemento irreversible que analiza los artefactos enviados contra los CVE conocidos, volviendo a analizar cuando se publican nuevas definiciones.
• CCSP (Proveedor de Servicios de Nube Certificado): el papel de socio Red Hat bajo el cual OpenShift se despliega en el cliente en infraestructura de IONOS validada en lugar de ofrecerse como un servicio gestionado de IONOS.
• BYOS (Traiga su propia suscripción): el modelo de SUSE Rancher Prime en el que IONOS factura la infraestructura y SUSE factura las licencias, con el cliente autogestionando la plataforma.