Dans l'écosystème cloud-native actuel, Kubernetes s'est imposé comme le standard de facto pour l'orchestration de conteneurs. On déploie des pods en quelques secondes, en récupérant souvent des images depuis des registres variés. Mais dans cette course à l'innovation, une question essentielle demeure : savez-vous vraiment ce qui tourne dans votre cluster ?
Si votre réponse repose sur la confiance ou sur des hypothèses concernant l'intégrité des images, votre cluster fonctionne sans doute à l'aveugle — une approche risquée à l'heure où les attaques sur la supply chain se sophistiquent.
À mesure que les organisations s'appuient sur les conteneurs pour packager et déployer leurs applications, garantir l'intégrité et l'authenticité des images exécutées dans leurs clusters devient primordial. La vérification des images n'est pas un simple nice-to-have : c'est un pilier non négociable d'une posture de sécurité Kubernetes solide.
Pourquoi vérifier vos images de conteneurs ?
Les images de conteneurs sont les briques fondamentales de vos applications Kubernetes. Elles encapsulent votre code, ses dépendances et son environnement d'exécution. Mais cette commodité peut aussi introduire des vulnérabilités si les images ne sont pas correctement contrôlées.
Voici pourquoi la vérification des images n'est plus une option :
- 🔓 Attaques sur la supply chain : les attaquants ciblent de plus en plus la chaîne d'approvisionnement logicielle, en injectant du code malveillant dans des images d'apparence légitime. Sans vérification, vous êtes une victime en sursis.
- 🐞 Vulnérabilités connues : de nombreuses images reposent sur des couches de base contenant des paquets obsolètes ou vulnérables. Des images non vérifiées peuvent vous exposer à des CVE (Common Vulnerabilities and Exposures) à votre insu.
- 🔧 Mauvaises configurations : images exécutées en root, ports inutilisés exposés, secrets en dur dans le code — autant de portes d'entrée pour les attaquants.
- 🎯 Erreur humaine : un développeur peut utiliser par mégarde une version d'image plus ancienne, ou au nom similaire mais non sécurisée. Sans contrôles stricts, ces erreurs filent en production.
- 📋 Non-conformité : des standards comme PCI DSS, SOC 2 ou HIPAA exigent une preuve d'intégrité et de provenance du logiciel. Exécuter des images non vérifiées, c'est s'exposer à des audits ratés et à des sanctions réglementaires.
Sans système de vérification robuste, votre cluster Kubernetes risque de devenir un environnement non maîtrisé, peuplé de logiciels non contrôlés, exposant votre organisation à des risques considérables.
Comment Kyverno résout et simplifie la vérification des images
L'écosystème Kubernetes propose des outils puissants pour aller au-delà de la simple confiance et imposer une intégrité vérifiable. Kyverno, moteur de policies conçu spécifiquement pour Kubernetes, se distingue tout particulièrement.
Kyverno joue le rôle d'admission controller : il intercepte les requêtes API et applique des policies avant que les workloads ne soient admis dans le cluster. Il est donc idéal pour faire respecter les règles de vérification des images dès le déploiement.
Principaux atouts de Kyverno pour la vérification des images :
- ✅ Vérification des signatures : imposez une signature cryptographique pour garantir que les images sont authentiques et non altérées.
- 📜 Contrôle des attestations : validez les métadonnées signées de l'image, comme le statut de scan ou la provenance du build.
- 🔒 Restriction des registres : n'autorisez que les images issues de sources de confiance.
- 🏷️ Standards de tagging : assurez-vous que les images utilisent des tags explicites (et non
latest) et respectent les conventions de versioning.
Exemples de policies Kyverno pour la vérification des images
Passons en revue quelques exemples concrets. Avant de les utiliser, vérifiez que Kyverno est bien installé dans votre cluster.
Scénario 1 : restreindre les images aux registres approuvés
Une policy simple mais efficace consiste à n'autoriser que les images provenant des registres de confiance de votre organisation.
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-image-registries
spec:
validationFailureAction: Enforce # Block deployments if validation fails
rules:
- name: validate-registries
match:
any:
- resources:
kinds:
- Pod
- Deployment
- StatefulSet
- Job
- CronJob
validate:
message: "Images must be pulled from approved registries (gcr.io or my.private.registry)."
pattern:
spec:
containers:
- image: "gcr.io/* | my.private.registry/*" # Allowed registry patterns
Si une image issue d'un registre non approuvé est utilisée, le déploiement sera bloqué avec un message de validation explicite.
Scénario 2 : garantir la signature des images avec Cosign
Cosign, composant clé du projet Sigstore, est un outil largement adopté pour signer et vérifier cryptographiquement les artefacts logiciels, et stocker ces signatures et attestations dans un registre OCI. Assurez-vous que les clés publiques nécessaires à la vérification sont accessibles, soit via des Kubernetes Secrets, soit via une URL.
Kyverno s'intègre directement à Cosign via sa règle verifyImages pour appliquer des policies validant les signatures d'images de conteneurs et les attestations in-toto. Seules les images de confiance et vérifiées sont alors déployées dans le cluster Kubernetes.
Voici une ClusterPolicy Kyverno qui garantit que toutes les images déployées dans le namespace production sont signées par une clé publique spécifique :
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image-signatures
spec:
validationFailureAction: Enforce
background: false
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: verify-image-signature
match:
any:
- resources:
kinds:
- Pod
namespaces:
- production
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # Adjust to your image pattern
attestors:
- count: 1
entries:
- keys:
publicKeys: | #The public key may either be defined in the policy directly or reference a standard Kubernetes Secret elsewhere in the cluster by specifying it in the format k8s://<namespace>/<secret_name>. The named Secret must specify a key cosign.pub containing the public key used for verification.
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyourPublicKeyContentHere...
-----END PUBLIC KEY-----
Une image signée se déploie normalement, tandis qu'une tentative d'exécution d'une image non signée déclenche une erreur de policy comme celle-ci :
Scénario 3 : vérifier les attestations de scan de vulnérabilités
Pour préserver l'intégrité de la supply chain logicielle, il est essentiel de scanner régulièrement les images à la recherche de vulnérabilités. Les scans réalisés au moment du build sont un bon point de départ, mais ils doivent être répétés à mesure que de nouvelles vulnérabilités apparaissent. Kyverno aide à imposer cette pratique en vérifiant la présence d'attestations prouvant qu'une image a récemment fait l'objet d'un scan réussi.
Voici une ClusterPolicy Kyverno issue de Trivy qui impose une validation sur les images des Pods, afin de s'assurer que leurs scans de vulnérabilités datent de moins d'une semaine.
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-vulnerabilities
spec:
validationFailureAction: enforce
webhookTimeoutSeconds: 30
failurePolicy: Fail
rules:
- name: not-older-than-one-week
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "registry.example.com/*:*" # Adjust to your image pattern
attestations:
- predicateType: cosign.sigstore.dev/attestation/vuln/v1
conditions:
- all:
- key: "{{ time_since('','{{metadata.scanFinishedOn}}','') }}"
operator: LessThanOrEquals
value: "168h"
Kyverno bloquera la création du pod si l'image n'a pas été scannée récemment et qu'il lui manque une attestation de scan signée par Cosign.
Ce ne sont là que quelques exemples. La flexibilité de Kyverno permet un contrôle bien plus granulaire : vérification de tags ou labels d'images spécifiques, voire rejet des images présentant des vulnérabilités de gravité élevée à partir des données d'attestation.
La vérification des images n'est pas une simple bonne pratique : c'est une nécessité fondamentale pour sécuriser des opérations cloud-native. Des outils comme Kyverno offrent un moyen puissant et flexible de passer d'une posture de confiance aveugle à une sécurité réellement vérifiable. Et lorsqu'il s'agit de s'assurer que vos workloads sont non seulement sécurisés, mais aussi correctement dimensionnés, fiables et économiques, des plateformes comme PerfectScale viennent compléter les outils de sécurité en analysant en continu les workloads Kubernetes pour identifier des opportunités d'optimisation — sans compromettre la performance ni la conformité.
En mettant en place la vérification des signatures d'images, le contrôle des attestations et la restriction des registres, vous bâtissez une défense solide face à un large éventail de menaces visant la supply chain logicielle.
Explorez la documentation Kyverno et Cosign pour commencer dès aujourd'hui à sécuriser vos workloads conteneurisés. Si vous souhaitez en savoir plus ou êtes intéressé par nos services, n'hésitez pas à nous contacter ici.