Sécurisez votre chaîne d'approvisionnement d'images de conteneurs

Stockez les images dans un registre privé contrôlé par RBAC

Le contrôle fondamental d'une chaîne d'approvisionnement logicielle sécurisée est un registre fermé par défaut, avec un RBAC par projet ou par équipe. Pas un bucket partagé sur lequel tout le monde peut pousser, ni un registre public avec des images visibles par défaut.

Les comptes robots font le reste du travail :
• Limitez chaque compte robot à un seul projet.
• Donnez aux étapes de build des autorisations de push en écriture seule, et aux étapes de déploiement des autorisations de pull en lecture seule.
•    Exécutez un projet par équipe, afin qu'un projet compromis reste isolé.
•    Appliquez une politique centrale à chaque projet, auditée de manière centralisée.
•    Gardez les identifiants personnels et administrateur totalement hors des builds automatisés.

Analysez chaque image à la recherche de CVE au push et au pull

L'analyse des vulnérabilités doit se produire à deux moments :
• Au push, afin qu'une nouvelle image soit analysée dès sa création.
• Au pull, afin qu'une vérification de politique soit à nouveau effectuée avant qu'une image plus ancienne ne soit déployée par rapport à une base de données de vulnérabilités plus récente.

Une image qui était propre en mars peut présenter trois vulnérabilités connues en juin, et seule une vérification au moment du pull les détectera.

L'analyse asynchrone au push ne ralentit pas le build. L'analyse s'exécute en parallèle pendant que le pipeline continue, et les résultats sont disponibles avant que l'image ne soit promue vers la production.

Signez les artefacts avec Cosign ou Notary v2

La signature d'une image enregistre de manière cryptographique qui l'a construite et confirme qu'elle n'a pas été altérée pendant le transit. Elle établit une chaîne de confiance du système de construction jusqu'au cluster.

La confiance est ce que vise réellement un attaquant. La porte dérobée xz-utils a fonctionné parce que la confiance envers un mainteneur s'était accumulée pendant des années, et les attaquants sont assez patients pour exploiter un mainteneur plutôt qu'un pare-feu.

Cosign, qui fait partie du projet Sigstore, et Notary v2 sont aujourd'hui les deux approches open source dominantes pour la signature d'images de conteneurs.

Sans signature ni politique de vérification, il est impossible de prouver après un incident que l'image exécutée en production est l'artefact exact construit par votre pipeline. Une image non signée et une image altérée sont indiscernables au moment du déploiement.

Appliquez une politique de déploiement avant que les images n'atteignent Kubernetes

L'analyse et la signature ne sont utiles que si quelque chose les impose. Un contrôleur d'admission Kubernetes, Kyverno ou OPA Gatekeeper étant les deux choix courants, vérifie chaque image au moment du déploiement et rejette tout ce qui ne respecte pas la politique :
• CVE critiques non résolues.
• Une signature Cosign manquante ou invalide.
• Une image provenant d'un registre non approuvé.

C'est le contrôle qui rend les autres applicables, et celui qu'une attaque doit déjouer. Il transforme l'analyse d'image d'une simple métrique rapportée en un verrou strict, de sorte qu'aucune image non analysée n'atteigne la production, ce qui constitue l'exigence de conformité réelle.

Les deux points d'application sont complémentaires. Le registre bloque l'envoi, le cluster bloque le déploiement, et une attaque qui parvient à contourner l'un se heurte toujours à l'autre. Tous deux reposent sur un cluster que vous n'avez pas à gérer vous-même lorsque vous utilisez le Managed Kubernetes Service d'OVHcloud.

Ces quatre contrôles techniques viennent s'ajouter, et non se substituer, aux pratiques organisationnelles qui réduisent le risque de manière plus large. Les pratiques de ce type sont peu coûteuses par rapport à un incident, et chacune est une pratique qu'un auditeur peut vérifier.

Ce sont les pratiques qui transforment une conception sécurisée en un système sécurisé, et chacune d'elles est une pratique centrale, et non un supplément optionnel :

• Mettez régulièrement à jour les dépendances et les composants tiers pour vous protéger contre les exploits connus.
• Limitez l'accès aux systèmes de build sensibles et aux clés de signature.
• Formez les employés et organisez des sessions de sensibilisation à la sécurité, afin que les ingénieurs reconnaissent un paquet compromis ou une tentative de phishing contre un compte de mainteneur.
• Effectuez des exercices basés sur un plan de réponse aux incidents, afin qu'une équipe sache comment réagir rapidement lorsqu'un contrôle échoue.
• Vérifiez l'intégrité des logiciels en continu plutôt que de la supposer, afin que chaque artefact reste sécurisé par une vérification plutôt que par habitude.

Toute faille de sécurité potentielle dans cette liste est généralement une lacune de processus, et non une lacune d'outillage.
Chaque composant logiciel que vous intégrez, ainsi que chaque composant transitif sous-jacent, est une décision prise une fois par quelqu'un et rarement remise en question. Une application moderne comprend des centaines de composants de ce type, la plupart provenant d'une partie externe que personne n'a rencontrée.

L'inventaire des composants est donc la pratique dont tout le reste dépend. La gestion des dépendances, qui consiste à savoir quels logiciels et quels composants proviennent d'un tiers, est ce qui rend un SBOM (nomenclature logicielle) utile une fois que vous en avez un.

Un SBOM répertorie chaque composant et chaque version, ce qui transforme un nouvel avis CVE en une requête de cinq minutes au lieu d'une semaine d'archéologie. Sans cela, la réponse honnête à la question de savoir si vous êtes exposé est que personne ne le sait.

Harbor sous le capot : Diplômé de la CNCF, standard OCI, open source

Managed Private Registry est une instance entièrement gérée de Harbor, une technologie open source diplômée de la CNCF conçue pour le stockage de conteneurs et de chartes Helm, avec la sécurité comme fonctionnalité de premier ordre plutôt que comme un ajout.

Auto-héberger Harbor signifie exécuter et corriger PostgreSQL, Redis, les services principaux de Harbor et le scanner, ainsi que le TLS et les mises à jour de chacun de ces composants.

OVHcloud supprime cette couche opérationnelle. Vous créez un registre, poussez des images et configurez une politique, tandis que l'infrastructure Harbor sous-jacente est de la responsabilité d'OVHcloud. Cela libère votre équipe de cybersécurité pour la modélisation des menaces et la résilience de la chaîne d'approvisionnement plutôt que pour la correction d'une base de données.

Comme Harbor est open source et basé sur des standards, il n'y a pas de verrouillage propriétaire. Les images sont au format OCI standard, donc la migration vers un Harbor auto-hébergé ou un autre registre compatible OCI ne nécessite aucune étape de conversion ni aucun format de tirage propriétaire à défaire.

Cette transparence est en soi une propriété de sécurité. Une communauté mondiale de relecteurs, et non un seul fournisseur, examine le code qui exécute votre registre.

Un projet central avec de nombreux relecteurs détecte un commit malveillant plus rapidement qu'un projet fermé, et les renseignements sur les menaces concernant les vulnérabilités de Harbor ou Trivy vous parviennent par les mêmes canaux publics que ceux utilisés par tous les autres utilisateurs.

Analyse des vulnérabilités avec Trivy : Détection des CVE à l'envoi et au tirage

OVHcloud Managed Private Registry inclut Trivy, le scanner intégré de Harbor, activé au niveau du projet.

Configurez l'analyse à l'envoi (scan-on-push) afin que chaque image soit vérifiée dès son arrivée, puis définissez un seuil de gravité des CVE. Avertir en cas de gravité ÉLEVÉE, bloquer en cas de gravité CRITIQUE est une politique de départ recommandée.

Une analyse au moment du tirage (pull) vérifie ensuite une image plus ancienne par rapport à une base de données de vulnérabilités plus récente.

Une politique de déploiement Harbor empêche le tirage d'images contenant des CVE CRITIQUES non résolues dans les espaces de noms de production, ce qui rend le résultat de l'analyse exploitable plutôt qu'informatif.

Signature d'image avec Cosign et Notary v2

Le service est basé sur Harbor, il prend donc en charge l'analyse des vulnérabilités et le stockage des charts Helm documentés pour le produit.

La signature d'image elle-même s'exécute via l'outil open source standard Cosign dans votre pipeline CI/CD, en pointant vers le registre OVHcloud plutôt que vers un service de signature propriétaire.

Application des politiques : bloquer les images avec des CVE critiques avant le déploiement

La politique côté registre, bloquant les CVE CRITIQUES et exigeant une signature valide, ne représente que la moitié de l'histoire de l'application.

L'autre moitié s'exécute dans Kubernetes lui-même. Une politique d'admission Kyverno ou OPA Gatekeeper rejette toute image sans signature Cosign valide, ou présentant une vulnérabilité grave non résolue, indépendamment de la manière dont elle a été déployée ou de l'acteur concerné.

Ensemble, ils assurent un blocage des CVE appliqué par politique de bout en bout. Il s'agit d'une configuration que vous définissez délibérément, et non d'une garantie automatique.

Stockage de charts Helm (conforme OCI)

Les charts Helm sont stockés dans le même format conforme OCI que les images de conteneurs, dans la même structure de projet, avec les mêmes RBAC et comptes robots.

Les équipes qui empaquettent les déploiements sous forme de charts Helm bénéficient d'un registre unique pour les deux types d'artefacts, au lieu d'un dépôt de charts séparé à sécuriser et à maintenir.

Comptes robots : push en écriture seule pour les builds, pull en lecture seule pour les déploiements

Créez un projet Harbor par équipe ou par application, puis émettez des comptes robots limités exactement à ce dont chaque étape a besoin : push en écriture seule pour l'étape de build, pull en lecture seule pour l'étape de déploiement.
N'intégrez jamais d'identifiants administrateur ou personnels, ou la clé d'un compte robot,

dans une définition de build. Un compte robot en lecture seule qui fuite constitue un incident contenu. Une information d'identification d'administrateur ayant fuité entre les mains d'un acteur externe ne l'est pas.

Pour les clés de signature Cosign spécifiquement, OVHcloud Key Management Service prend en charge le « bring-your-own-key » avec un stockage basé sur HSM conforme à la norme FIPS 140-2, ce qui évite de stocker vos clés sur les ordinateurs portables des développeurs et les exécuteurs CI.

Exemple GitHub Actions : construire, analyser, signer et pousser

Une seule étape couvre l'ensemble du contrôle :
1.    Construisez l'image.
2.    Poussez-la avec un compte robot en écriture seule.
3.    Attendez le résultat de l'analyse Trivy.
4.    Signez avec Cosign uniquement si l'analyse respecte le seuil de CVE configuré.

Cette séquence maintient une barrière stricte entre l'existence d'une image et le fait qu'une image soit suffisamment fiable pour être signée, plutôt que de signer inconditionnellement au moment de la construction.

Le même modèle s'applique que la construction s'exécute sur GitHub Actions, GitLab CI ou Tekton. Seule la syntaxe pour appeler le registre et l'analyseur change, quel que soit le langage de programmation dans lequel votre application est écrite.

Politiques d'admission Kyverno sur Managed Kubernetes Service

Sur OVHcloud Managed Kubernetes Service, une politique Kyverno, définie comme un fichier de politique Kubernetes standard, vérifie chaque spécification de pod entrante pour une signature Cosign valide et rejette le déploiement si la signature est manquante ou invalide.

Combiné avec la politique CVE côté registre, cela boucle la boucle entre ce que vous construisez et ce que le cluster peut exécuter. Une image non signée ou non analysée ne démarre jamais, quel que soit l'auteur de la demande de déploiement.

Les images de conteneurs transportent de la propriété intellectuelle, et l'exposition au CLOUD Act avec elles

Une image de conteneur regroupe le code applicatif, les couches de configuration et parfois les variables d'environnement : une part significative de la propriété intellectuelle de votre organisation. Un registre central est l'endroit où cette propriété intellectuelle se concentre, c'est pourquoi sa juridiction est importante. Stocker cette image chez un fournisseur dont le siège est aux États-Unis, même avec des centres de données dans l'UE, la place sous la juridiction du CLOUD Act américain, car l'exposition suit la société mère, et non le lieu de stockage. La même logique s'applique à tout déploiement AWS ECR, Google Artifact Registry ou Docker Hub : La juridiction du CLOUD Act américain s'applique indépendamment de la région.

Siège social européen, pas de société mère américaine, RGPD par juridiction

Une image de conteneur regroupe le code applicatif, les couches de configuration et parfois les variables d'environnement : une part significative de la propriété intellectuelle de votre organisation.

Un registre central est l'endroit où cette propriété intellectuelle se concentre, c'est pourquoi sa juridiction est importante.

Le stockage de cette image chez un fournisseur dont le siège est aux États-Unis, même s'il possède des centres de données dans l'UE, la place sous la juridiction du CLOUD Act américain, car l'exposition suit la société mère plutôt que le lieu de stockage.

Il en va de même pour tout registre exploité par un fournisseur dont le siège social est aux États-Unis : La juridiction du CLOUD Act américain s'applique indépendamment de la région.

Siège social européen, pas de société mère américaine, RGPD par juridiction

OVHcloud est un opérateur européen sans société mère américaine, il n'y a donc aucune exposition structurelle au CLOUD Act sur tout ce qui est stocké dans le registre.

L'infrastructure du registre fonctionne sous le RGPD par juridiction plutôt que par engagement politique.

La protection juridique provient de l'emplacement de l'entreprise et de l'infrastructure, et non d'une promesse contractuelle ajoutée à une infrastructure qu'une autorité étrangère pourrait toujours contraindre.

Disponibilité 3-AZ à Paris et Milan, Accord de niveau de service (SLA) de disponibilité de 99,99 % sur MKS Standard

Le registre fonctionne en 3-AZ à Paris avec une haute disponibilité intégrée. Une défaillance d'une seule zone n'interrompt ni vos builds ni vos déploiements, ce qui est important car une panne du registre bloque les deux.

Le service Managed Kubernetes Service Standard fonctionne en 3-AZ à Paris et à Milan avec un Accord de niveau de service (SLA) de disponibilité de 99,99 %, de sorte que le registre et le cluster qui en dépend partagent la même posture de disponibilité au lieu que l'un soit le maillon faible.

MKS Free pour commencer, MKS Standard pour la production

Le service Kubernetes géré dispose d'une offre gratuite pour le développement et la préproduction, suffisante pour valider l'ensemble de la chaîne d'approvisionnement logicielle : registre, analyse, signature et politique d'admission, avant de s'engager sur un cluster de production.

Le verrouillage de version sur vos fichiers de politique rend cette validation reproductible.

Lorsque vous êtes prêt pour le trafic de production, MKS Standard ajoute l'offre 3-AZ avec un Accord de niveau de service (SLA) de disponibilité de 99,99 %, et les mêmes politiques Kyverno ou OPA Gatekeeper sont transférées sans changement sur les deux offres.

Les équipes gérant plusieurs clusters y ajoutent Managed Rancher Service pour disposer d'un plan de contrôle unique pour l'ensemble.

Pour commencer : activez votre registre et déployez des images sécurisées dès aujourd'hui

Créez un projet Managed Private Registry, poussez une image et activez l'analyse et la signature. MKS Free couvre le développement et la pré-production sans frais, vous pouvez donc valider toute la chaîne de politique avant que le trafic de production n'en dépende. Pour plusieurs clusters de production, des secteurs réglementés ou des pools de nœuds GPU, un architecte solutions OVHcloud vous aidera à dimensionner le projet. Le hub d'orchestration de conteneurs est l'endroit où apprendre le reste.