Unité 6.4 : Container Registry et choix de la plateforme

Introduction

Toute plateforme conteneurisée a besoin d'un emplacement de confiance pour le stockage des images et d'une justification solide quant à l'identité des personnes autorisées à les pousser et à les tirer. Sur IONOS CLOUD, le Container Registry vous fournit ce stockage, mais il régit l'accès d'une manière qui surprendra un architecte s'attendant au modèle basé sur les rôles, courant dans les registres des hyperscalers : l'accès se fait uniquement par jeton, et la discipline appliquée à ces jetons constitue l'intégralité de votre gouvernance d'accès. Cette unité commence par établir ce modèle de gouvernance et la décision de sélection de plateforme sous-jacente à tout parc de conteneurs, puis se termine par la création d'un registre, la limitation de portée d'un jeton et l'authentification d'un client dans le Data Center Designer.

FinCorp, notre fintech allemande soumise à des réglementations, met en place un pipeline CI/CD pour déployer ses nouveaux services liés à l'IA sur Managed Kubernetes. Le registre est positionné entre le parc de construction et le cluster, si bien que le modèle d'accès qu'il impose devient un contrôle de gouvernance que les auditeurs de FinCorp examineront. La question de la sélection de plateforme se pose en parallèle : FinCorp doit décider si Managed Kubernetes supporte ses charges de travail conteneurisées ou si une distribution déployée par le client est justifiée, et cette décision repose entièrement sur la volonté de prendre en charge le cycle de vie du plan de contrôle.

1. Accès par jeton uniquement et gouvernance par la discipline des jetons

Le Container Registry ne dispose d'aucun contrôle d'accès basé sur les rôles. Il n'y a ni rôles, ni utilisateurs associés à des autorisations au sein du registre, et aucun langage de politique. L'accès est accordé exclusivement par le biais de jetons d'accès au registre, de sorte que la posture de sécurité du registre est précisément la discipline que vous imposez à ces jetons. Un architecte provenant d'un registre avec RBAC doit intérioriser cette inversion : vous n'assignez pas un rôle à un principal, vous émettez une crédentiale et vous en définissez le périmètre.

Un jeton porte un périmètre construit à partir de trois éléments. Le Type est soit Registry, ce qui permet au jeton de lister les dépôts du registre, soit Repository, ce qui permet au jeton de gérer le contenu d'un ou de plusieurs dépôts nommés. Le Path nomme les dépôts auxquels le jeton accède, où * est un joker qui accorde l'accès à tous les dépôts. L'Action est une ou plusieurs des valeurs Pull, Push et Admin, où Admin permet au jeton de supprimer des artefacts. Un jeton capable de pousser doit également porter 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 dépôt au-delà de ce périmètre de jeton ; le registre n'offre pas de ACL plus fines sur un dépôt unique que ce que le modèle de jeton exprime.

Les jetons existent en deux types : un jeton d'accès au registre permanent, et un jeton temporaire qui porte une date d'expiration. La durée minimale d'expiration que vous pouvez définir sur un jeton temporaire est d'une heure. Le secret d'un jeton est affiché exactement une fois lors de sa création ; si vous le perdez, vous ne pouvez pas le récupérer, vous ne pouvez que remplacer le jeton. 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 pertinent sur le plan de la sécurité est ce qui se produit à 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 la crédentiale, et qu'il n'y a ni accès anonyme ni niveau de pull public sur lequel se reposer. Le pull, comme le push, nécessite toujours un jeton valide.

Puisque le registre ne vous offre que des jetons, la gouvernance est la discipline des jetons, et cette discipline est concrète. Émettez un jeton par étape de pipeline plutôt qu'une crédentiale partagée : l'étape de build qui pousse les images reçoit un jeton push-and-pull limité aux dépôts qu'il produit, tandis que l'étape de déploiement qui tire les images sur le cluster reçoit un jeton pull-only. Limitez le périmètre de 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 joker. Définissez une expiration qui correspond à la durée de vie prévue de la crédentiale et effectuez la rotation en émettant un remplaçant avant l'expiration de l'ancien, car l'expiration supprime le jeton définitivement et un pipeline non roté s'arrête simplement. Gardez ces jetons à l'écart des crédentiales personnelles ; le modèle de jeton existe précisément pour que CI/CD ne s'authentifie jamais en tant que personne. Pour FinCorp, cela correspond clairement aux attentes de ses auditeurs : chaque étape de pipeline détient une crédentiale distincte, au périmètre étroit et expirante, et l'absence de secrets partagés à longue durée de vie est démontrable à partir de la liste des jetons.

Le registre est chiffré au repos et publie un SLA de disponibilité de 99,95 % par service. Il est actuellement disponible dans l'emplacement Francfort (DE/FRA), et à la fois le nom du registre et son emplacement sont immuables après la création, de sorte que l'emplacement est une décision de placement prise une seule fois. Le nom du registre doit en outre être unique au niveau global pour tous les clients, ne contenir que des caractères alphanumériques et des tirets, avoir une longueur comprise entre 3 et 63 caractères, commencer par une lettre de a à z, et se terminer par un caractère alphanumérique.

2. Le balayage des vulnérabilités comme bascule à sens unique

Le balayage des vulnérabilités est une fonctionnalité complémentaire qui analyse le logiciel présent dans vos images de conteneurs par rapport aux vulnérabilités et expositions connues (CVE). Un balayage s'exécute à chaque fois qu'un artefact est poussé, puis à nouveau lorsque de nouvelles définitions de vulnérabilités sont publiées. La couverture suit ainsi à la fois le renouvellement de vos images et l'évolution du catalogue CVE, avec une fenêtre de rebalayage de 30 jours. Les résultats fournissent des détails CVE par artefact que vous pouvez intégrer dans une porte CI/CD, ce qui constitue la valeur ajoutée pour une entreprise soumise à des réglementations comme FinCorp, qui doit démontrer sa diligence raisonnable sur sa chaîne d'approvisionnement.

Le détail architectural essentiel est l'irréversibilité. Une fois le balayage des vulnérabilités activé sur un registre, il ne peut plus être désactivé par la suite. L'activation est donc une décision délibérée et à sens unique, et non un réglage à activer pour un essai puis à désactiver par la suite. Considérez-le comme une propriété à laquelle vous vous engagez pour toute la durée de vie du registre, et prenez cette décision de manière consciente au moment de sa création ou après, plutôt que de découvrir cette contrainte en tentant de l'inverser. Pour FinCorp, la décision est simple : le balayage reste activé, mais l'architecte doit néanmoins le consigner comme un engagement irréversible.

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

La décision concernant la plateforme de conteneurs sur IONOS CLOUD porte fondamentalement sur la propriété du plan de contrôle Kubernetes et de l'obligation de conformité associée, et non sur l'équivalence fonctionnelle entre les distributions. Trois options reposent sur le même substrat de calcul et de stockage d'IONOS CLOUD, mais diffèrent considérablement en termes de modèle opérationnel.

Le tableau suivant résume les trois options et l'attribution du cycle de vie et de l'obligation de conformité.

Managed Kubernetes est l'option par défaut. IONOS CLOUD exploite le plan de contrôle et le fournit gratuitement, tandis que vous ne payez que pour les pools de nœuds. Le cycle de vie du plan de contrôle, ses mises à niveau et sa disponibilité sont la responsabilité d'IONOS CLOUD, selon un 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 inclus dans le périmètre d'attestation BSI C5. C'est cette précision de conformité par service que la plateforme impose : vous ne pouvez pas affirmer que « le Cluster est C5 », car l'attestation C5 de type 1 (délivré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é d'IONOS CLOUD. IONOS CLOUD n'offre pas de solution OpenShift gérée et ne vend ni ne facture d'abonnements OpenShift. Au lieu de cela, IONOS CLOUD et Red Hat ont conjointement validé OpenShift exécuté sur l'infrastructure d'IONOS CLOUD, produisant une référence d'implémentation pour les partenaires Red Hat Certified Cloud Service Provider (CCSP). Le client (le partenaire CCSP) déploie et gère ses propres Clusters et assume donc l'ensemble du cycle de vie du plan de contrôle. La licence est de type « apportez votre propre licence », avec des abonnements souscrits auprès de Red Hat ou d'un distributeur individuel ; les ressources IONOS CLOUD sous-jacentes sont facturées au tarif standard, sans supplément spécifique à OpenShift. Avant d'exécuter OpenShift en production, les partenaires doivent planifier une validation Red Hat par l'intermédiaire d'un représentant d'IONOS CLOUD, qui coordonne la revue confirmant que le déploiement répond aux exigences de production de Red Hat. Choisissez cette option uniquement si la plateforme OpenShift est une exigence stricte et si vous êtes prêt à en assumer l'exploitation.

SUSE Rancher Prime suit un modèle de déploiement autogéré sur IONOS CLOUD. IONOS CLOUD 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 de la configuration et de l'administration des paysages de Clusters en aval. Le modèle commercial est de type « apportez votre propre abonnement », où IONOS CLOUD facture l'infrastructure (Compute Engine, Block Storage, réseau) aux tarifs standards 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 CLOUD. Le partenariat est positionné pour la gestion souveraine de Kubernetes dans la région DACH, avec des alignements sur BSI IT-Grundschutz, NIS2, le RGPD de l'UE et les exigences de la chaîne d'approvisionnement de l'UE ; la réserve opérationnelle est que c'est vous, et non IONOS CLOUD, qui exploitez le plan de gestion. La présentation antérieure de Rancher Prime comme un service géré exploité par SUSE ne tient pas : 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 sacrifient la commodité d'un plan de contrôle géré au profit de capacités spécifiques à la distribution, et transfèrent par conséquent le cycle de vie du plan de contrôle et la majeure partie de l'obligation de conformité sur les équipes de FinCorp. Sauf si OpenShift ou Rancher est une exigence déclarée, Managed Kubernetes est le choix à moindre charge, supporté par IONOS CLOUD, qui est déjà inclus dans le périmètre IT-Grundschutz.

Une limite qui s'applique aux trois options : lorsque les attestations et les certifications couvrent la couche d'infrastructure d'IONOS CLOUD, elles ne couvrent que cette couche, et non les charges de travail du client exécutées sur le Cluster. Un Cluster reposant sur une infrastructure attestée ne rend pas l'application qui y est hébergée conforme ; la conformité des charges de travail reste la responsabilité du client, quel que soit le système d'exploitation qui gère le plan de contrôle.

3.1 Isolation multi-Cluster par rapport à l'isolation par espace de noms

Au sein de la plateforme choisie, la séparation des charges de travail est une décision à deux niveaux. L'isolation par espace de noms divise logiquement un seul Cluster : les locataires partagent le même plan de contrôle et les mêmes pools de nœuds, et vous imposez la séparation par des politiques réseau intra-Cluster et des quotas de ressources. C'est l'option la moins coûteuse et la plus dense, et le choix par défaut approprié pour les environnements qui partagent une frontière 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 Clusters distincts, donnant à chacun son propre plan de contrôle et une frontière de rayon d'impact stricte. C'est la séparation la plus robuste, à privilégier lorsque les charges de travail relèvent de périmètres de conformité différents, lorsqu'un voisin bruyant ou hostile est inacceptable, ou lorsqu'une mise à niveau ou une panne ne doit pas pouvoir traverser les limites entre locataires. Sur Managed Kubernetes, le coût du choix libre du multi-Cluster est limité par un quota de Clusters par contrat (une valeur par défaut qui peut être augmentée sur demande via le Support d'IONOS CLOUD), de sorte qu'un parc nécessitant de nombreux locataires isolés de manière stricte doit planifier autour de cette limite, éventuellement en se répartissant sur plusieurs contrats (le contrat étant la frontière de gouvernance établie dans le Module 2). Le modèle de FinCorp consiste à conserver sa charge de travail de production réglementée dans son propre Cluster, isolé du Cluster de développement partagé, précisément afin que le périmètre de conformité de la production ne soit pas entremêlé avec les changements de développement.

Déroulement de la mise en œuvre de DCD

Vous allez créer un Container Registry, activer l'analyse des vulnérabilités, générer un jeton au périmètre restreint, et authentifier un client Docker auprès de celui-ci. Cela met en œuvre le modèle d'accès décrit à la section 1 : un registre unique dont la seule surface d'accès est un ensemble de jetons à périmètre défini et à durée limitée, prêt à soutenir le pipeline de FinCorp. Le seul prérequis est un utilisateur contractuel disposant de l'autorisation de créer le registre.

Objectif de construction : Créer un registre, émettre un jeton à périmètre défini, authentifier un client.

Étapes (dans Data Center Designer) :

1. Accédez à Menu > Containers > Container Registry pour ouvrir le gestionnaire Container Registry.
2. Cliquez sur Add a Registry. Fournissez un Name. Retenez que le nom est permanent, unique au niveau global pour tous les clients, limité aux caractères alphanumériques et aux tirets, d'une longueur de 3 à 63 caractères, commençant par une lettre et se terminant par un caractère alphanumérique.
3. Choisissez l'Location dans la liste déroulante. Celle-ci est également immuable après la création, et le registre est disponible dans l'emplacement Frankfurt (DE/FRA). Prenez cette décision de manière réfléchie.
4. Configurez éventuellement le Garbage Collection Schedule en sélectionnant le ou les jours et l'heure (UTC) de l'exécution hebdomadaire qui libère le stockage occupé par les couches d'image non référencées. La collecte des ordures est désactivée par défaut ; notez que le registre est en lecture seule pendant son exécution, placez donc la fenêtre en dehors des heures de pointe.
5. Décidez de l'Vulnerability Scanning. Vous pouvez l'activer ici, mais une fois activé, il ne peut plus être désactivé ultérieurement ; considérez donc son activation comme un engagement irréversible. (Vous pouvez également l'ajouter à un registre existant par la suite via la section Properties du registre, où la même irréversibilité s'applique.)
6. Cliquez sur Add Registry. Le registre et son stockage sont créés ; il est prêt à l'emploi lorsque son statut atteint Running. Le nom d'hôte du registre n'est alloué qu'une fois le statut Running atteint.
7. Sélectionnez le registre en cours d'exécution et ouvrez l'onglet Tokens, puis cliquez sur Add Token. Donnez au jeton un Name (également non modifiable ultérieurement).
8. Définissez le périmètre du jeton : réglez le Type (Registry pour lister les dépôts, ou Repository pour gérer le contenu des dépôts), saisissez le Path des dépôts auxquels il accède (évitez l' joker * sauf si l'étape a réellement besoin de tous les dépôts), et sélectionnez le ou les Action(s). Pour un jeton de poussée à l'étape de construction, sélectionnez Push et, car la poussée l'exige, également Pull. Pour une expiration facultative, définissez une date d'expiration d'au moins une heure. Enregistrez le jeton et copiez son secret immédiatement : il n'est affiché qu'une seule fois.
9. Authentifiez un client. À l'aide de l'interface en ligne de commande Docker, connectez-vous au nom d'hôte du registre en utilisant le jeton comme identifiant :

docker login {registry-name}.cr.de-fra.ionos.com

Username and Password: supply the token credentials (not a personal login)

Le client peut désormais effectuer des opérations de poussée (push) et de récupération (pull) dans le cadre de portée du jeton. Le point architectural est que c'est le seul chemin d'authentification : il n'y a pas de récupération anonyme, de sorte que même l'accès en lecture passe par un jeton à portée définie.

**Erreurs courantes :**

- Considérer l'analyse des vulnérabilités comme réversible. C'est un commutateur à sens unique ; une fois activé, il ne peut pas être désactivé. Prenez votre décision avant de l'activer.
- S'attendre à pouvoir désactiver un jeton expiré. L'expiration supprime le jeton, elle ne le désactive pas, de sorte qu'une identifiante de pipeline non renouvelée disparaît et le pipeline se rompt. Renouvelez en émettant un jeton de remplacement avant l'expiration.
- Essayer de récupérer un secret de jeton perdu. Le secret est affiché exactement une seule fois lors de la création ; s'il est perdu, vous devez créer un nouveau jeton.
- Accorder `Push` sans `Pull`. Un jeton capable de pousser doit également porter la capacité de récupération, sinon la poussée échoue.
- Recourir à un joker `*` ou à un jeton unique partagé entre tous les stades. Émettez un jeton à portée étroite pour chaque stade du 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 déplacer le registre plus tard. À la fois le nom et l'emplacement sont immuables ; choisir le mauvais emplacement signifie recréer le registre.
- S'appuyer sur un niveau de récupération publique pour les images de base. Il n'y a pas d'accès anonyme ni de niveau de récupération publique ; chaque récupération nécessite un jeton.

Résumé

Le Container Registry d'IONOS CLOUD gère l'accès à l'aide de jetons à portée limitée et à durée d'expiration, plutôt que par un contrôle d'accès basé sur les rôles. La sécurité du registre est donc exactement la discipline que vous appliquez à ses jetons : un jeton par étape du pipeline, à portée étroite, à durée d'expiration, renouvelé par remplacement, et tenu à l'écart des identifiants personnels. L'analyse de vulnérabilités est un module complémentaire précieux mais irréversible, et le nom ainsi que l'emplacement du registre sont permanents. La décision de sélection de la plateforme repose sur la question de qui assume le cycle de vie du plan de contrôle et la charge de conformité : Managed Kubernetes conserve les deux aspects chez IONOS CLOUD, dans le cadre de l'IT-Grundschutz, tandis qu'OpenShift et Rancher Prime sont déployés par le client et transfèrent cette responsabilité à vous. Séparez les charges de travail à l'aide d'espaces de noms lorsqu'elles partagent une frontière de confiance, et à l'aide de plusieurs clusters lorsqu'elles nécessitent une séparation stricte, dans la limite du plafond de clusters par contrat.

Points clés :

• Le Container Registry ne dispose pas de RBAC ; l'accès est exclusivement basé sur des jetons, sans accès anonyme et sans niveau de tirage public. La gouvernance repose sur la discipline des jetons.
• La portée du jeton est définie par le Type (Registry ou Repository), le Path et l'Action (Pull/Push/Admin) ; Push nécessite Pull, et le secret du jeton n'est affiché qu'une seule fois.
• Les jetons sont supprimés à leur expiration, et non désactivés ; le renouvellement s'effectue en émettant un jeton de remplacement avant l'expiration. La durée d'expiration minimale est d'une heure.
• L'analyse de vulnérabilités est un commutateur à sens unique : une fois activé, il ne peut pas être désactivé. Le nom et l'emplacement du registre sont immuables.
• Managed Kubernetes conserve le cycle de vie du plan de contrôle et la conformité chez IONOS CLOUD (IT-Grundschutz, et non C5) ; OpenShift (CCSP, BYOL) et Rancher Prime (autogéré, BYOS) sont déployés par le client, transférant cette charge à vous.
• Les attestations couvrent uniquement la couche d'infrastructure d'IONOS CLOUD, et non les charges de travail du client sur le cluster.
• Utilisez les espaces de noms pour une séparation souple avec une frontière partagée, et plusieurs clusters pour une séparation stricte, dans la limite de votre quota de clusters par contrat (augmentable sur demande).

Terminologie importante :

• Jeton d'accès au registre : l'unique identifiant d'accès au Container Registry, limité par le type, le chemin et l'action ; permanent ou temporaire (avec une expiration qui le supprime en fin de vie).
• Analyse de vulnérabilités : un module complémentaire irréversible qui analyse les artefacts poussés par rapport aux CVE connues, en effectuant de nouvelles analyses à mesure que de nouvelles définitions sont publiées.
• CCSP (Certified Cloud Service Provider) : le rôle de partenaire Red Hat dans le cadre duquel OpenShift est déployé par le client sur une infrastructure IONOS CLOUD validée, plutôt qu'offert en tant que service géré IONOS CLOUD.
• BYOS (Bring Your Own Subscription) : le modèle SUSE Rancher Prime dans lequel IONOS CLOUD facture l'infrastructure et SUSE facture les licences, le client assurant lui-même la gestion de la plateforme.