Unité 6.4 : Registre de conteneurs et sélection de plateforme

Introduction

Chaque plateforme de conteneurs a besoin d'un endroit de confiance pour stocker des images et d'une explication solide pour savoir qui peut les pousser et les tirer. Sur IONOS, le Container Registry vous offre cet espace de stockage, mais il réglemente l'accès d'une manière qui surprendra un architecte qui s'attend à un modèle basé sur les rôles courant dans les registres des hyperscalers : l'accès se fait uniquement par jeton, et la discipline que vous appliquez à ces jetons constitue l'ensemble de votre gouvernance d'accès. Cette unité établit d'abord ce modèle de gouvernance et la décision de sélection de plateforme derrière tout patrimoine de conteneurs, puis se termine par la création d'un registre, la définition de la portée d'un jeton et la connexion d'un client dans le Data Center Designer.

FinCorp, notre fintech réglementé allemand, met en place un pipeline CI/CD pour déployer ses nouveaux services adjacents à l'IA sur le Managed Kubernetes. Le registre est situé entre la ferme de construction et le Cluster, donc le modèle d'accès qu'il impose devient un contrôle de gouvernance que les auditeurs de FinCorp examineront. La question de sélection de plateforme se pose en parallèle : FinCorp doit décider si le Managed Kubernetes supporte ses charges de travail de conteneurs ou si une distribution déployée par le client est justifiée, et cette décision dépend entièrement de qui est prêt à assumer le cycle de vie du plan de contrôle.

1. Accès et gouvernance uniquement par jeton et discipline de jeton

Le Container Registry ne dispose pas de contrôle d'accès basé sur des rôles. Il n'y a pas de rôles, pas d'utilisateurs associés à des autorisations à l'intérieur du registre, et pas de langage de politique. L'accès est accordé exclusivement par le biais de jetons d'accès au registre, donc la posture de sécurité du registre est précisément la discipline que vous imposez à ces jetons. Un architecte venant d'un registre avec RBAC doit internaliser cette inversion : vous n'attribuez pas un rôle à un principal, vous créez un identifiant et le définissez.

Un jeton porte une étendue construite à partir de trois parties. Le Type est soit Registry, qui permet au jeton de lister les référentiels dans le registre, soit Repository, qui permet au jeton de gérer le contenu d'un ou plusieurs référentiels nommés. Le Chemin nomme les référentiels que le jeton atteint, où * est un caractère générique qui accorde l'accès à tous les référentiels. L'Action est une ou plusieurs de Pull, Push, et Admin, où Admin permet au jeton de supprimer des artefacts. Un jeton capable de push doit également porter un pull : lorsque vous sélectionnez Push, vous devez également définir Pull. Il n'y a pas de liste de contrôle d'accès par référentiel au-delà de cette étendue de jeton ; le registre n'offre pas de listes de contrôle d'accès plus fines sur un référentiel unique que le modèle de jeton ne l'exprime.

Les jetons viennent en deux sortes : un jeton d'accès permanent au registre, et un jeton temporaire qui porte une date d'expiration. La durée d'expiration minimale que vous pouvez définir sur un jeton temporaire est d'une heure. Le secret d'un jeton est affiché exactement une fois à la création ; si vous le perdez, vous ne pouvez pas le récupérer, seulement le remplacer. Un jeton a trois états de cycle de vie : enabled, disabled, et deleted. Vous pouvez désactiver un jeton pour le suspendre, mais le fait de sécurité pertinent est ce qui se passe à l'expiration : un jeton expiré est supprimé, et non simplement désactivé. Cela signifie qu'une expiration est une fin de vie définitive pour l'identifiant, et il n'y a pas d'accès anonyme et pas de niveau de tirage public pour lequel faire appel. Le tirage, comme la poussée, nécessite toujours un jeton valide.

Puisque le registre ne vous donne que des jetons, la gouvernance est la discipline de jeton, et la discipline est concrète. Émettez un jeton par étape de pipeline plutôt qu'un identifiant partagé : l'étape de construction qui pousse des images obtient un jeton de push et de pull étendu aux référentiels qu'il produit, tandis que l'étape de déploiement qui tire des images sur le Cluster obtient un jeton de pull uniquement. Étendez chaque jeton aussi étroitement que l'étape le permet, en préférant un jeton de type Repository sur un chemin nommé plutôt qu'un caractère générique. Définissez une expiration qui correspond à la vie prévue de l'identifiant et faites pivoter en créant un remplacement avant que l'ancien n'expire, puisque l'expiration supprime le jeton purement et simplement et un pipeline non pivoté s'arrête simplement. Gardez ces jetons hors des informations d'identification personnelles entièrement ; le modèle de jeton existe précisément pour que CI/CD n'authentifie jamais comme une personne. Pour FinCorp, cela se traduit clairement par les attentes de ses auditeurs : chaque étape de pipeline détient un identifiant distinct, étendu étroitement, expirant, et l'absence de secrets partagés à long terme est démontrable à partir de la liste de jetons.

Le registre est chiffré à REST et publie un SLA de disponibilité de 99,95 % par service. Il est actuellement disponible dans l'emplacement de Francfort (DE/FRA), et à la fois le nom du registre et son emplacement sont immuables après création, donc l'emplacement est une décision de placement prise une fois. Le nom du registre doit également être globalement unique à travers tous les clients, contenir uniquement des caractères alphanumériques et des tirets, être compris entre 3 et 63 caractères, commencer par une lettre a-z, et se terminer par un caractère alphanumérique.

2. Analyse de vulnérabilités en tant que bascule à sens unique

L'analyse de vulnérabilités est une fonctionnalité complémentaire qui analyse les logiciels dans vos images de conteneurs par rapport aux vulnérabilités et aux expositions communes (CVE) connues. Un scan est exécuté chaque fois qu'un artefact est poussé et à nouveau lorsque de nouvelles définitions de vulnérabilités sont publiées, de sorte que la couverture suit à la fois la rotation de vos images et le catalogue de CVE en évolution, avec une fenêtre de re-scan de 30 jours. Les résultats donnent des détails CVE par artefact que vous pouvez intégrer à une CI/CD, ce qui constitue la valeur pour une entreprise réglementée comme FinCorp qui doit faire preuve de diligence raisonnable dans sa chaîne d'approvisionnement.

Le détail architectural qui compte est l'irréversibilité. Une fois l'analyse de vulnérabilités activée sur un registre, elle ne peut pas être désactivée plus tard. L'activation est donc une décision délibérée et unidirectionnelle, et non un paramètre à activer pour un essai et à désactiver ensuite. Traitez-la comme une propriété à laquelle vous vous engagez pour la durée de vie du registre, et décidez-en consciemment au moment de la création ou après, plutôt que de découvrir la contrainte lorsque vous essayez de l'inverser. Pour FinCorp, la décision est simple : l'analyse reste activée, mais l'architecte devrait néanmoins l'enregistrer comme un engagement irréversible.

3. Sélection de la plateforme : Qui contrôle le cycle de vie du plan de contrôle

La décision de plateforme de conteneurs sur IONOS est fondamentalement une question de savoir qui possède le plan de contrôle Kubernetes et sa charge de conformité, et non de parité de fonctionnalités entre les distributions. Trois options s'appuient sur le même substrat de calcul et de stockage IONOS, mais diffèrent nettement dans leur modèle opérationnel.

Le tableau suivant résume les trois options et où se situe le cycle de vie et la charge de conformité.

Managed Kubernetes est la valeur par défaut. IONOS exploite le plan de contrôle et le fournit gratuitement, tandis que vous payez uniquement pour les Node Pools. Le cycle de vie du plan de contrôle, ses mises à jour, sa disponibilité, est de la responsabilité d'IONOS sous une SLA de 99,95 % par service. En matière de conformité, Managed Kubernetes relève du périmètre de certification BSI IT-Grundschutz (ISO 27001) dans les centres de données allemands, mais il n'est pas dans le périmètre d'attestation BSI C5. Il s'agit de la précision de conformité par service que la plateforme exige : vous ne pouvez pas dire "le Cluster est C5", car l'attestation de type 1 C5 (accordée le 2023-11-07) couvre Compute Engine, Cloud Cubes, et S3 Object Storage, et non Managed Kubernetes.

Red Hat OpenShift n'est pas un service géré IONOS. IONOS ne propose pas de solution OpenShift gérée et ne vend ni ne facture d'abonnements OpenShift. Au lieu de cela, IONOS et Red Hat ont validé conjointement OpenShift s'exécutant sur l'infrastructure IONOS, produisant une implémentation de référence pour les partenaires Red Hat Certified Cloud Service Provider (CCSP). Le client (le partenaire CCSP) déploie et gère ses propres grappes et possède donc l'ensemble du cycle de vie du plan de contrôle. La licence est apportée par le client, avec des abonnements provenant de Red Hat ou d'un distributeur individuel ; les ressources IONOS sous-jacentes sont facturées au tarif standard sans surcharge OpenShift spécifique. Avant de lancer OpenShift en production, les partenaires doivent planifier une validation Red Hat par l'intermédiaire d'un représentant IONOS Cloud, qui coordonne l'examen confirmant que le déploiement répond aux exigences de production Red Hat. Choisissez ce chemin uniquement lorsque la plateforme OpenShift elle-même est une exigence stricte et que vous êtes prêt à en assumer l'exploitation.

SUSE Rancher Prime suit un modèle de déploiement auto-géré sur IONOS. IONOS ne propose pas Rancher Prime en tant que service géré : le client est responsable de l'ensemble du cycle de vie de l'environnement Rancher Prime, y compris l'installation, la mise à l'échelle et la maintenance continue du serveur de gestion, ainsi que la configuration et l'administration des paysages Cluster en aval. Le modèle commercial est apporté par le client, où IONOS facture l'infrastructure (Compute Engine, Block Storage, réseau) aux tarifs standard et SUSE (ou le distributeur SUSE du client) facture les licences Rancher Prime et SUSE Linux Enterprise Server, sans frais d'intégration cachés de la part d'IONOS. Le partenariat est positionné pour la gestion souveraine de la région DACH Kubernetes, avec des alignements sur BSI IT-Grundschutz, NIS2, les exigences de chaîne d'approvisionnement de l'UE GDPR ; la clause opérationnelle est que vous, et non IONOS, exécutez le plan de gestion. La formulation antérieure de Rancher Prime en tant que service géré par SUSE n'est plus valable : SUSE fournit l'abonnement et le support, mais le client exploite la plateforme.

Le résumé honnête pour FinCorp : les options déployées par le client échangent la commodité d'un plan de contrôle géré pour des capacités spécifiques à la distribution, et ce faisant, ils transfèrent le cycle de vie du plan de contrôle et la majeure partie de la charge de conformité sur les équipes de FinCorp. À moins que OpenShift ou Rancher ne soit une exigence déclarée, Managed Kubernetes est le choix à faible charge, pris en charge par IONOS, qui se situe déjà dans le périmètre IT-Grundschutz.

Une limite qui s'applique aux trois : lorsque les attestations et les certifications couvrent la couche d'infrastructure IONOS, elles couvrent uniquement cette couche, et non les charges de travail du client s'exécutant sur les Cluster. Un Cluster situé sur une infrastructure attestée ne rend pas l'application qui s'y exécute conforme ; la conformité des charges de travail reste de la responsabilité du client, quel que soit la distribution qui exploite le plan de contrôle.

3.1 Multi-Cluster versus isolation d'espace de noms

Dans quelle que soit la plateforme que vous choisissez, la séparation des charges de travail est une décision à deux niveaux. L'isolation d'espace de noms divise un seul Cluster logiquement : les locataires partagent le même plan de contrôle et les mêmes Node Pools, et vous imposez la séparation avec des stratégies de réseau et des quotas de ressources dans le Cluster. Il s'agit de l'option la moins chère et la plus dense, et c'est le choix par défaut pour les environnements qui partagent une limite de confiance et de conformité, par exemple plusieurs équipes de développement internes de FinCorp.

L'isolation multi-Cluster place les charges de travail dans des grappes séparées, donnant à chacune son propre plan de contrôle et une limite de rayon d'explosion rigide. Il s'agit de la séparation la plus forte et de celle à utiliser lorsque les charges de travail se situent dans différents périmètres de conformité, lorsque l'on ne peut pas accepter un voisin bruyant ou hostile, ou lorsque une mise à jour ou une défaillance ne doit pas être en mesure de se propager entre les locataires. Sur Managed Kubernetes, le coût du choix de l'isolation multi-Cluster est limité par une quote-part de Cluster par contrat (une valeur par défaut qui peut être augmentée sur demande via le support IONOS Cloud), donc un patrimoine qui nécessite de nombreux locataires isolés doit planifier autour de ce plafond, potentiellement en les répartissant sur plusieurs contrats (le contrat étant la limite de gouvernance établie dans le Module 2). Le modèle de FinCorp est de maintenir sa charge de travail de production réglementée dans son propre Cluster, isolé du Cluster de développement partagé, précisément pour que le périmètre de conformité de production ne soit pas enchevêtré avec les fluctuations de développement.

DCD Déploiement étape par étape

Vous allez créer un registre de conteneurs, activer l'analyse de vulnérabilités, créer un jeton à portée étroite, et authentifier un client Docker contre celui-ci. Cela réalise le modèle d'accès de la Section 1 : un registre unique dont la seule surface d'accès est un ensemble de jetons à portée étroite et temporaires, prêt à soutenir le pipeline de FinCorp. Le seul prérequis est un utilisateur contractuel avec la permission de créer le registre.

Objectif de construction : Créer un registre, émettre un jeton à portée étroite, authentifier un client.

Étapes (dans le Data Center Designer) :

1. Allez à Menu > Conteneurs > Registre de conteneurs pour ouvrir le gestionnaire de registre de conteneurs.
2. Cliquez sur Ajouter un registre. Fournissez un Nom. Rappelez-vous que le nom est permanent, unique à l'échelle mondiale pour tous les clients, alphanumérique et tirets uniquement, 3 à 63 caractères, commençant par une lettre et se terminant alphanumériquement.
3. Choisissez l'Emplacement dans le menu déroulant. Cela est également immuable après la création, et le registre est disponible dans l'emplacement Francfort (DE/FRA). Prenez cette décision délibérément.
4. Configurez facultativement le Plan de collecte des déchets, en sélectionnant le(s) jour(s) et l'heure (UTC) pour l'exécution hebdomadaire qui libère le stockage occupé par les couches d'images non référencées. La collecte des déchets est désactivée par défaut ; notez que le registre est en lecture seule pendant son exécution, donc placez la fenêtre en dehors des heures de pointe.
5. Décidez de l'Analyse de vulnérabilités. Vous pouvez l'activer ici, mais une fois activée, elle ne peut pas être désactivée plus tard, donc traitez l'activation comme un engagement à sens unique. (Vous pouvez également l'ajouter à un registre existant plus tard via la section Propriétés du registre, où la même irréversibilité s'applique.)
6. Cliquez sur Ajouter un registre. Le registre et son stockage sont créés ; il est prêt à l'emploi lorsque son état atteint En cours d'exécution. Le nom d'hôte du registre est alloué uniquement une fois qu'il atteint l'état En cours d'exécution.
7. Sélectionnez le registre en cours d'exécution et ouvrez l'onglet Jetons, puis cliquez sur Ajouter un jeton. Donnez un Nom au jeton (qui ne peut pas être modifié plus tard).
8. Définissez la portée du jeton : définissez le Type (Registry pour répertorier les référentiels, ou Repository pour gérer le contenu des référentiels), entrez le Chemin des référentiels qu'il atteint (évitez le * sauf si le stade a réellement besoin de chaque référentiel), et sélectionnez l'Action(s). Pour un jeton de poussée de construction, sélectionnez Pousser et, car la poussée nécessite cela, également Tirer. Pour une expiration facultative, définissez une date d'expiration d'au moins une heure. Enregistrez le jeton et copiez son secret maintenant : il n'est affiché qu'une seule fois.
9. Authentifiez un client. En utilisant la CLI Docker, connectez-vous à l'hôte du registre avec le jeton comme informations d'identification :

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

Le client peut maintenant envoyer et recevoir des données dans la portée du jeton. Le point architectural est que ceci est le seul chemin d'authentification : il n'y a pas de téléchargement anonyme, donc même l'accès en lecture passe par un jeton étendu.

Erreurs courantes :

• Traiter l'analyse de vulnérabilités comme une opération réversible. Il s'agit d'un commutateur unidirectionnel ; une fois activé, il ne peut pas être désactivé. Prenez une décision avant de l'activer.
• S'attendre à désactiver un jeton expiré. L'expiration supprime le jeton, elle ne le désactive pas, donc un jeton d'informations d'identification de pipeline non tourné disparaît et le pipeline est interrompu. Effectuez une rotation en créant un remplacement avant l'expiration.
• Essayer de récupérer un secret de jeton perdu. Le secret est affiché exactement une fois lors de la création ; si il est perdu, vous devez créer un nouveau jeton.
• Accorder Push sans Pull. Un jeton capable d'envoyer des données doit également prendre en charge la réception, ou l'envoi échoue.
• Utiliser un * générique ou un jeton partagé unique pour toutes les étapes. Émettez un jeton étendu étroitement pour chaque étape de pipeline ; le registre n'a pas de RBAC, donc la portée du jeton est votre seul contrôle d'accès.
• Supposer que vous pouvez renommer ou relocaliser le registre plus tard. Le nom et l'emplacement sont immuables ; choisir le mauvais emplacement signifie recréer le registre.
• Compter sur un niveau de téléchargement public pour les images de base. Il n'y a pas d'accès anonyme et pas de niveau de téléchargement public ; chaque téléchargement nécessite un jeton.

Résumé

Le Registre de conteneurs IONOS gouverne l'accès par le biais de jetons à péremption, étendus plutôt que par un contrôle d'accès basé sur les rôles, donc la sécurité du registre est exactement la discipline que vous appliquez à ses jetons : un par étape de pipeline, étroitement étendu, à péremption, tourné par remplacement, et gardé hors des informations d'identification personnelles. L'analyse de vulnérabilité est un ajout précieux mais irréversible, et le nom et l'emplacement du registre sont permanents. La décision de sélection de plateforme tourne sur qui possède le cycle de vie du plan de contrôle et la charge de conformité : Managed Kubernetes garde les deux avec IONOS à l'intérieur de la portée IT-Grundschutz, tandis que OpenShift et Rancher Prime sont déployés par le client et déplacent cette propriété vers vous. Séparez les charges de travail avec des espaces de noms lorsqu'ils partagent une limite de confiance et avec plusieurs grappes lorsqu'ils ont besoin d'une limite dure, dans le plafond Cluster par contrat.

Points clés :

• Le Registre de conteneurs n'a pas de RBAC ; l'accès est uniquement par jeton, sans accès anonyme et sans niveau de tir public. La gouvernance est la discipline du jeton.
• La portée du jeton est de type (Registre ou Référentiel) plus chemin plus action (Tirer/Pousser/Admin); Pousser nécessite Tirer, et le secret du jeton est affiché une seule fois.
• Les jetons sont supprimés à l'expiration, et non désactivés ; tournez en émettant un remplacement avant l'expiration. L'expiration minimale est d'une heure.
• L'analyse de vulnérabilité est un basculement unidirectionnel : une fois activée, elle ne peut pas être désactivée. Le nom et l'emplacement du registre sont immuables.
• Managed Kubernetes garde le cycle de vie du plan de contrôle et la conformité avec IONOS (IT-Grundschutz, et non C5) ; OpenShift (CCSP, BYOL) et Rancher Prime (auto-géré, BYOS) sont déployés par le client, déplaçant cette charge vers vous.
• Les attestations couvrent uniquement la couche d'infrastructure IONOS, et non les charges de travail du client sur le Cluster.
• Utilisez des espaces de noms pour une séparation de limite partagée et plusieurs grappes pour une séparation dure, dans votre quota Cluster par contrat (augmenter sur demande).

Terminologie importante :

• Jeton d'accès au registre : la seule credenciale d'accès pour le Registre de conteneurs, étendue par type, chemin et action ; permanente ou temporaire (avec une expiration la supprimant à la fin de sa vie).
• Analyse de vulnérabilité : un ajout irréversible qui analyse les artefacts poussés contre les CVE connus, réanalysant à mesure que de nouvelles définitions sont publiées.
• CCSP (Certified Cloud Service Provider) : le rôle de partenaire Red Hat sous lequel OpenShift est déployé par le client sur une infrastructure IONOS validée plutôt que proposé comme un service IONOS géré.
• BYOS (Bring Your Own Subscription) : le modèle SUSE Rancher Prime où IONOS facture l'infrastructure et SUSE facture les licences, avec le client auto-gérant la plateforme, et Cluster, Cluster, et enfin Cluster, ainsi que Managed Kubernetes, et Red Hat.