Vous connaissez sûrement déjà Aqua Security Trivy, un outil tout en un pour scanner vos images de conteneurs et votre infrastructure. L'intégrer à votre CI/CD pour remonter rapidement les failles de sécurité ou les erreurs de configuration est un bon début, mais que se passe-t-il une fois vos conteneurs déployés ? Une nouvelle CVE n'attendra pas votre prochain déploiement pour apparaître.
Découvrez comment Trivy Operator automatise la sécurité de votre cluster Kubernetes. À chaque nouvelle ressource déployée, l'opérateur prend le relais pour scanner les vulnérabilités des images en cours d'exécution, auditer les configurations et détecter les secrets exposés. Trivy Operator expose aussi des métriques qui pourront être intégrées dans un dashboard Grafana.
Commençons par un petit rappel. Trivy est un outil en ligne de commande qui permet de lancer plusieurs types de scanners vers différentes cibles.
Les scanners (ce que Trivy peut détecter) :
Les cibles (ce que Trivy peut scanner) :
Quelques exemples de commandes.
Scanner une image Python :
trivy image python:3.4-alpine
Trivy va télécharger sa base de vulnérabilités et nous afficher un report summary.
Ce rapport indique 37 vulnérabilités identifiées pour le système d’exploitation et des vulnérabilités sur des packages Python installés.
En regardant le rapport plus en détail, nous pouvons voir le détail de chaque CVE identifiée : leur id et dans quelle version elles sont corrigées.
Pour aller plus loin, il est possible :
# Select what security issues to detect
trivy image --scanners vuln,misconfig,secret,license python:3.4-alpine
# Filter by severities
trivy image --severity HIGH,CRITICAL python:3.4-alpine
# Ignore unfixed/unpatched vulnerabilities
trivy image --ignore-unfixed python:3.4-alpine
Il est aussi possible de lancer trivy pour scanner du code en local pour identifier des erreurs de configuration dans votre IaC. Une des fonctionnalités intéressantes est toutefois de pouvoir scanner directement un cluster Kubernetes.
trivy k8s --report summary
Cette commande va lancer un scan complet du cluster et nous afficher un résumé des failles de sécurité et des erreurs de configuration.
C’est parfait pour de l’exploratoire mais au quotidien, nous voulons pouvoir intégrer ces données à nos outils de monitoring comme Prometheus et Grafana pour suivre leur évolution.
Trivy Operator s'appuie sur Trivy pour scanner en continu votre cluster Kubernetes. Les résultats des scans sont résumés sous forme de rapports de sécurité via des Custom Resource Definitions (CRD). L'opérateur fonctionne en surveillant les changements d'état du cluster et déclenche automatiquement des scans de sécurité en réponse.
Trivy Operator génère les rapports suivants:
Prérequis:
Installer Prometheus + Grafana :
helm install prom oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack \
--namespace monitoring \
--create-namespace \
--set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \
--set-json 'prometheus.prometheusSpec.serviceMonitorSelector={}' \
--set-json 'prometheus.prometheusSpec.serviceMonitorNamespaceSelector={}' \
--set grafana.enabled=true
Pour simplifier la démo, nous configurons Prometheus pour sélectionner tous les services monitor.
Installer Trivy Operator:
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator \
--namespace trivy-system \
--create-namespace \
--version 0.29.0 \
--set operator.builtInTrivyServer=true \
--set serviceMonitor.enabled=true
Pour tester, nous allons déployer une ancienne version de NGINX.
kubectl create deployment nginx --image nginx:1.16
La génération des rapports peut prendre un peu de temps.
Pour NGINX vous allez voir apparaître les rapports suivants :
Pour les consulter, vous pouvez utiliser simplement une commande kubectl :
kubectl get vulnerabilityreports -o wide
Résultat :
Vous pouvez consulter les autres rapports avec les commandes suivantes :
kubectl get configauditreports -o wide
kubectl get exposedsecretreports -o wide
kubectl get sbomreports -o wide
Vous pouvez aussi consulter les cluster resources:
k get clusterinfraassessmentreports -o wide
NAME SCANNER AGE CRITICAL HIGH MEDIUM LOW
node-0 Trivy 17h 0 0 0 0
Connectez-vous sur l’interface de Prometheus pour vérifier que les métriques sont bien présentes. Vous pouvez tester les métriques suivantes :
trivy_image_vulnerabilitiestrivy_resource_configauditstrivy_image_exposedsecretsConnectez-vous à Grafana et importez un le dashboard Trivy Operator Dashboard avec l’id 17813. Une fois sur le dashboard vous trouverez un aperçu des failles présentes sur le cluster.
Si vous consultez la section sur les vulnérabilités, vous trouverez un tableau permettant de filtrer et trier les vulnérabilités par image. Si nous voulons identifier les images avec le plus de failles critiques, on obtient :
Libre à vous ensuite de personnaliser le dashboard en fonction de vos besoins.
En conclusion, si l'intégration de Trivy dans la CI/CD est indispensable, Trivy Operator va plus loin en transformant la sécurité en un processus continu et automatisé au sein de Kubernetes. Trivy Operator génère un état des lieux complet et constant des vulnérabilités et erreurs de configuration. De plus, l'intégration avec Prometheus et un dashboard Grafana permet de suivre leur évolution dans le temps. Trivy Operator est donc un atout majeur du DevSecOps pour une gestion proactive et réactive de la sécurité de votre cluster.
D'un point de vue concret, j'ai pu mettre en œuvre Trivy Operator en conditions réelles de production chez un client. Une question revient souvent : quel est l'impact sur la stabilité du cluster ? Mon retour d'expérience est très clair : il n'y a eu aucun impact sur les performances. Nous avons étroitement surveillé la consommation de ressources après l'installation et cela n'a jamais été un sujet de préoccupation. L'outil se déploie simplement et "se fait oublier" techniquement tout en rendant la sécurité visible.