Unidad 6.4: Container Registry y selección de plataforma

Introducción

Cada plataforma de contenedores necesita un lugar de confianza para almacenar imágenes y una justificación sólida sobre quién puede publicarlas y extraerlas. En IONOS CLOUD, el Container Registry le proporciona ese almacén, pero gobierna el acceso de una manera que sorprenderá a un arquitecto que espere el modelo basado en roles común en los registros de los proveedores de nube a gran escala: el acceso se realiza únicamente mediante tokens, y la disciplina que aplique a esos tokens constituye la totalidad de su gobernanza de acceso. Esta unidad establece primero ese modelo de gobernanza y la decisión de selección de plataforma que subyace a cualquier entorno de contenedores, y termina construyendo un registro, definiendo el alcance de un token e iniciando la sesión de un cliente dentro del Data Center Designer.

FinCorp, nuestra fintech alemana sujeta a regulación, está implementando una pipeline de CI/CD para desplegar sus nuevos servicios adyacentes a la inteligencia artificial en Managed Kubernetes. El registro se sitúa entre la granja de compilación y el clúster, por lo que el modelo de acceso que impone se convierte en un control de gobernanza que los auditores de FinCorp examinarán. La cuestión de la selección de plataforma va de la mano con esta: FinCorp debe decidir si Managed Kubernetes soporta sus cargas de trabajo de contenedores o si está justificada una distribución desplegada por el cliente, y esa decisión depende enteramente de quién está dispuesto a asumir el ciclo de vida del plano de control.

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

El Container Registry no tiene control de acceso basado en roles. No hay roles, no hay usuarios mapeados a permisos dentro del registro y no hay lenguaje de políticas. 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 usted imponga a esos tokens. Un arquitecto que proviene de un registro con RBAC debe internalizar esta inversión: usted no asigna a un principal un rol, usted emite una credencial y le define un alcance.

Un token porta un alcance construido a partir de tres partes. El Type es Registry, lo que permite al token listar los repositorios del registro, o Repository, lo 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 tiene acceso, donde * es un comodín que otorga acceso a todos los repositorios. El Action es uno o más de Pull, Push y Admin, donde Admin permite al token eliminar artefactos. Un token con capacidad de push debe también portar pull: cuando usted selecciona Push, debe también establecer Pull. No hay una lista de control de acceso por repositorio más allá de este acotado por token; el registro no ofrece ACLs de mayor granularidad sobre un solo repositorio que las que el modelo de token expresa.

Los tokens vienen en dos tipos: un token de acceso al registro permanente, y un token temporal que porta una fecha de expiración. La expiración mínima que usted 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 usted lo pierde, no puede recuperarlo, solo puede reemplazar el token. Un token tiene tres estados de ciclo de vida: enabled, disabled y deleted. Usted puede deshabilitar un token para suspenderlo, pero el hecho relevante para la seguridad es lo que ocurre en la expiración: un token expirado se elimina, no se deshabilita simplemente. Esto significa que una expiración es un fin de vida definitivo para la credencial, y no hay acceso anónimo ni un nivel de pull público al que recurrir. El pull, al igual que el push, siempre requiere un token válido.

Dado que el registro no le ofrece nada más que tokens, la gobernanza es la disciplina de tokens, y la disciplina es concreta. Emita un token por etapa de pipeline en lugar de una credencial compartida: la etapa de compilación que realiza push de imágenes obtiene un token de push y pull acotado a los repositorios que produce, mientras que la etapa de despliegue que realiza pull de imágenes al clúster obtiene un token solo de pull. Acope cada token tan estrechamente como la etapa permita, prefiriendo un token de tipo Repository en una ruta con nombre sobre un comodín. Establezca una expiración que coincida con la vida prevista de la credencial y realice rotación emitiendo un reemplazo antes de que el antiguo expire, ya que la expiración elimina el token por completo y un pipeline no rotado simplemente se detiene. Mantenga estos tokens fuera de las credenciales personales por completo; el modelo de tokens existe precisamente para que CI/CD nunca se autentifique como una persona. Para FinCorp, esto se ajusta claramente a las expectativas de sus auditores: cada etapa de pipeline posee una credencial distinta, de alcance estrecho y con expiración, y la ausencia de secretos compartidos de larga duración es demostrable desde la lista de tokens.

El registro está cifrado en reposo y publica un SLA de disponibilidad del 99,95% por servicio. Actualmente está disponible en la ubicación 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 ubicación tomada una sola vez. El nombre del registro debe además ser único a nivel global entre todos los clientes, contener solo caracteres alfanuméricos y guiones, tener entre 3 y 63 caracteres, comenzar con una letra de la a a la z, y terminar con un carácter alfanumérico.

2. El análisis de vulnerabilidades como conmutador de un solo sentido

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

El detalle arquitectónico que importa es la irreversibilidad. Una vez que el análisis de vulnerabilidades se habilita en un registro, no puede deshabilitarse posteriormente. Por lo tanto, habilitarlo es una decisión deliberada y de un solo sentido, no una configuración para activar en una prueba y desactivar después. Trátelo como una propiedad a la que se compromete durante la vida del registro, y decídalo conscientemente en el momento de la creación o después, en lugar de descubrir la restricción cuando intente revertirlo. Para FinCorp, la decisión es directa: el análisis permanece activado, pero el arquitecto aún debe documentarlo como un compromiso irreversible.

3. Selección de plataforma: ¿Quién gestiona el ciclo de vida del plano de control?

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

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

Managed Kubernetes es la opción predeterminada. IONOS CLOUD opera el plano de control y lo ofrece de forma gratuita, mientras que usted solo paga por los grupos de nodos. El ciclo de vida del plano de control, sus actualizaciones y su disponibilidad son responsabilidad de IONOS CLOUD bajo un SLA del 99,95 % por servicio. En cuanto al cumplimiento, Managed Kubernetes se encuentra dentro del alcance de la certificación BSI IT-Grundschutz (ISO 27001) en centros de datos alemanes, pero no está dentro del alcance de la atestación BSI C5. Esta es la precisión de cumplimiento por servicio que exige la plataforma: no puede decirse que "el Cluster es C5", porque la atestación C5 Tipo 1 (concedida 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 CLOUD. IONOS CLOUD no ofrece una solución administrada de OpenShift y no vende ni cobra por suscripciones de OpenShift. En su lugar, IONOS CLOUD y Red Hat validaron conjuntamente OpenShift ejecutándose en la infraestructura de IONOS CLOUD, produciendo una implementación de referencia para los socios Red Hat Certified Cloud Service Provider (CCSP). El cliente (el socio CCSP) despliega y gestiona sus propios Clusters y, por lo tanto, posee todo el ciclo de vida del plano de control. El licenciamiento es de tipo bring-your-own-license, con suscripciones obtenidas de Red Hat o de un distribuidor individual; los recursos subyacentes de IONOS CLOUD se facturan según la lista de precios regular, sin recargo específico por 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 para confirmar que la implementación cumple con los requisitos de producción de Red Hat. Elija esta ruta solo cuando la plataforma OpenShift en sí sea un requisito estricto y esté preparado para asumir su operación.

SUSE Rancher Prime sigue un modelo de despliegue autogestionado en IONOS CLOUD. IONOS CLOUD no proporciona Rancher Prime como servicio administrado: el cliente es responsable del ciclo de vida completo del entorno de Rancher Prime, incluida la instalación, la escalabilidad y el mantenimiento continuo del servidor de gestión, así como la configuración y administración de los paisajes de Clusters aguas abajo. El modelo comercial es de tipo bring-your-own-subscription, donde IONOS CLOUD factura la infraestructura (Compute Engine, Block Storage, red) 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 ocultas de integración por parte de IONOS CLOUD. La colaboración está posicionada para la gestión soberana de Kubernetes en la región DACH, con alineaciones a BSI IT-Grundschutz, NIS2, RGPD de la UE y requisitos de cadena de suministro de la UE; la advertencia operativa es que usted, no IONOS CLOUD, opera el plano de gestión. La formulación anterior de Rancher Prime como un servicio administrado operado por SUSE no se sostiene: SUSE proporciona la suscripción y el soporte, pero el cliente opera la plataforma.

El resumen honesto para FinCorp: las opciones desplegadas por el cliente intercambian la conveniencia 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, soportada por IONOS CLOUD, que ya se encuentra dentro del alcance de IT-Grundschutz.

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

3.1 Aislamiento multi-Cluster frente a aislamiento por espacio de nombres

Dentro de la plataforma que elija, la separación de cargas de trabajo es una decisión de dos niveles. El aislamiento por espacio de nombres divide lógicamente un único Cluster: los inquilinos comparten el mismo plano de control y los mismos grupos de nodos, y usted aplica la separación mediante políticas de red dentro del Cluster y cuotas de recursos. Es la opción más económica y densa, y el valor predeterminado adecuado para entornos que comparten un límite de confianza y cumplimiento, por ejemplo, varios equipos de desarrollo internos de FinCorp.

El aislamiento multi-Cluster coloca las cargas de trabajo en Clusters separados, otorgando a cada uno su propio plano de control y un límite duro de radio de impacto. Es la separación más fuerte y la que debe elegirse cuando las cargas de trabajo se encuentran en ámbitos de cumplimiento diferentes, cuando un vecino ruidoso o hostil no es aceptable, o cuando una actualización o falla no debe poder cruzar entre inquilinos. En Managed Kubernetes, el costo de elegir multi-Cluster libremente está limitado por una cuota de Clusters por contrato (un valor predeterminado que puede aumentarse bajo solicitud a través de Soporte de IONOS CLOUD), por lo que un conjunto de recursos que necesite muchos inquilinos con aislamiento duro debe planificar en torno a ese límite, posiblemente dividiéndose entre contratos (el contrato siendo el límite de gobernanza establecido en el Módulo 2). El patrón de FinCorp es mantener su carga de trabajo de producción regulada en su propio Cluster, aislada del Cluster de desarrollo compartido, precisamente para que el ámbito de cumplimiento de producción no se entrelace con los cambios de desarrollo.

Recorrido de implementación de DCD

Creará un Container Registry, habilitará la exploración de vulnerabilidades, emitirá un token con un alcance restringido y autenticará un cliente Docker contra él. Esto materializa el modelo de acceso de la Sección 1: un único registro cuya única superficie de acceso es un conjunto de tokens con alcance definido y caducidad, listo para respaldar la pipeline 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 definido y autenticar un cliente.

Pasos (en el Data Center Designer):

1. Vaya a Menú > Contenedores > Container Registry para abrir el Administrador de Container Registry.
2. Haga clic en Agregar un registro. Proporcione un Nombre. Recuerde que el nombre es permanente, único a nivel global para todos los clientes, solo alfanumérico y con guiones, de 3 a 63 caracteres, comenzando con una letra y terminando con un carácter alfanumérico.
3. Elija la Ubicación desde el menú desplegable. Esta también es inmutable después de la creación, y el registro está disponible en la ubicación Frankfurt (DE/FRA). Decida deliberadamente.
4. Configure opcionalmente la Programación de Recolección de Basura, seleccionando el día o los días y la 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, por lo que coloque la ventana fuera de las horas pico.
5. Decida sobre la Exploración de Vulnerabilidades. Puede habilitarla aquí, pero una vez habilitada no puede deshabilitarse posteriormente, por lo que trate la habilitación como un compromiso irreversible. (También puede agregarla 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. Se crean el registro y su almacenamiento; está listo para usarse cuando su estado alcance En ejecución. El nombre de host del registro se asigna solo cuando 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 al token un Nombre (tampoco se puede cambiar posteriormente).
8. Defina el alcance del token: establezca el Tipo (Registry para listar repositorios, o Repository para gestionar el contenido de los repositorios), 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 o las Acción(es). Para un token de push en una etapa de compilación, seleccione Push y, dado que push lo requiere, también Pull. Para una caducidad opcional, establezca una fecha de caducidad no inferior a una hora. Guarde el token y copie su secreto ahora: solo se muestra una vez.
9. Autentique un cliente. Utilizando la CLI de Docker, inicie sesión en el nombre de host del registro utilizando 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 ámbito del token. El punto arquitectónico es que esta es la única ruta de autenticación: no existe el pull anónimo, por lo que incluso el acceso de lectura se realiza a través de un token con ámbito definido.

**Errores comunes:**

- Considerar el escaneo de vulnerabilidades como reversible. Es un conmutador de un solo sentido; una vez habilitado, no se puede deshabilitar. Decida antes de habilitarlo.
- Esperar poder deshabilitar un token caducado. La caducidad elimina el token, no lo deshabilita, por lo que una credencial de pipeline no rotada desaparece y el pipeline se interrumpe. Rote el token creando un reemplazo antes de la caducidad.
- Intentar recuperar un secreto de token perdido. El secreto se muestra exactamente una vez en la creación; si se pierde, debe crear un nuevo token.
- Conceder `Push` sin `Pull`. Un token con capacidad de push también debe incluir pull, o el push fallará.
- Recurrir a un comodín `*` o a un token compartido único para todas las etapas. Emita un token con ámbito estrecho por cada etapa del pipeline; el registro no tiene RBAC, por lo que el ámbito del token es su único control de acceso.
- Suponer que puede renombrar o reubicar el registro más adelante. Tanto el nombre como la ubicación son inmutables; elegir la ubicación incorrecta implica recrear el registro.
- Confiar en un nivel de pull público para las imágenes base. No hay acceso anónimo ni nivel de pull público; cada pull requiere un token.

Resumen

El Container Registry de IONOS CLOUD gobierna el acceso mediante tokens con alcance limitado y fecha de expiración, en lugar de un control de acceso basado en roles. Por lo tanto, la seguridad del registro es exactamente la disciplina que se aplica a sus tokens: uno por cada etapa de la pipeline, con alcance estrecho, con fecha de expiración, rotados mediante reemplazo y mantenidos 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 asume el ciclo de vida del control plane y la carga de cumplimiento: Managed Kubernetes mantiene ambos con IONOS CLOUD dentro del alcance de IT-Grundschutz, mientras que OpenShift y Rancher Prime son implementados por el cliente y transfieren esa responsabilidad a usted. Separe las cargas de trabajo mediante namespaces cuando compartan un límite de confianza y mediante múltiples clusters cuando necesiten una separación estricta, dentro del límite de clusters por contrato.

Puntos clave:

• El Container Registry no tiene RBAC; el acceso es solo mediante tokens, sin acceso anónimo ni nivel de extracción pública. La gobernanza es la disciplina de los tokens.
• El alcance del token es Tipo (Registry o Repository) más Path más Action (Pull/Push/Admin); Push requiere Pull, y el secreto del token se muestra solo una vez.
• Los tokens se eliminan al expirar, no se desactivan; rotélos emitiendo un reemplazo antes de la expiración. La expiración mínima es de una hora.
• El análisis de vulnerabilidades es un conmutador de un solo sentido: una vez habilitado, no puede desactivarse. El nombre y la ubicación del registro son inmutables.
• Managed Kubernetes mantiene el ciclo de vida del control plane y el cumplimiento con IONOS CLOUD (IT-Grundschutz, no C5); OpenShift (CCSP, BYOL) y Rancher Prime (autogestionado, BYOS) son implementados por el cliente, transfiriendo esa carga a usted.
• Las atestaciones cubren solo la capa de infraestructura de IONOS CLOUD, nunca las cargas de trabajo del cliente en el cluster.
• Use namespaces para una separación suave con límites compartidos y múltiples clusters para una separación estricta, dentro de su cuota de clusters por contrato (solicite un aumento si es necesario).

Terminología importante:

• Token de acceso al registro: la única credencial de acceso para el Container Registry, con alcance definido por tipo, ruta y acción; permanente o temporal (con una fecha de expiración que lo elimina al final de su vida útil).
• Análisis de vulnerabilidades: un complemento irreversible que analiza los artefactos enviados contra CVE conocidos, volviéndolos a analizar a medida que se publican nuevas definiciones.
• CCSP (Certified Cloud Service Provider): el rol de socio de Red Hat bajo el cual OpenShift se implementa por el cliente en infraestructura de IONOS CLOUD validada, en lugar de ofrecerse como un servicio gestionado de IONOS CLOUD.
• BYOS (Bring Your Own Subscription): el modelo de SUSE Rancher Prime en el que IONOS CLOUD factura la infraestructura y SUSE factura las licencias, con el cliente autogestionando la plataforma.