kube-bench et trivy: Les outils indispensables pour auditer la sécurité des clusters Kubernetes et des images docker

---

Kube-bench

kube-bench est un outil développé par Aqua Security qui permet de vérifier si le cluster Kubernetes est configuré conformément aux recommandations du CIS Kubernetes Benchmark. Le CIS (Center for Internet Security) est une organisation qui publie des guides de bonnes pratiques pour sécuriser les systèmes informatiques. Le CIS benchmark Kubernetes fournit des lignes directrices détaillées pour renforcer la sécurité des clusters.

kube-bench automatise ces vérifications en exécutant une série de tests sur le cluster. Il couvre tous les composants Kubernetes, notamment :

• API Server

• etcd

• Controller Manager

• Scheduler

• Kubelet

• Policies de sécurité des pods

 

1. Conformité aux standards de sécurité
   Les CIS benchmarks sont reconnus comme des références en matière de sécurité. En utilisant kube-bench, on s'assure que le cluster respecte ces standards.

2. Détection des failles de configuration
   Une mauvaise configuration est l'une des principales causes de vulnérabilités dans les clusters Kubernetes. kube-bench identifie les problèmes courants, comme les autorisations excessives ou les paramètres non sécurisés.

3. Automatisation des audits
   Plutôt que de vérifier manuellement chaque paramètre, kube-bench automatise le processus, ce qui fait gagner du temps et réduit les erreurs humaines.

4. Amélioration continue de la sécurité
   En intégrant kube-bench dans le pipeline CI/CD ou dans des audits réguliers, on peut maintenir un niveau de sécurité élevé tout au long du cycle de vie des clusters k8s.

 

Utilisation de kube-bench

• kubebench a besoin d'acceder aux nodes kube pour effectuer ses checks. Dans ce cas, il faudra l'installer sur les nodes.
• Une methode plus simple est de l'executer avec docker sur les nodes.
• Une autre methode plus pratique est d'executer un job avec l'image et les config de kube-bench sur le cluster et recuperer les logs (rapport de scan) C'est cette dernière que nous allons voir et qui peut deployé en production.

Recuperer le job d'exemple dans le repo github de bube-bench et l'adapter selon vos besoins. Par exemple pour gke:

• Adapter le CIS benchmark qui convient selon la distribution kubernetes et la version CIS
• Ajouter la spec ttlSecondsAfterFinished pour auto clean le job après un certain temps.

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  ttlSecondsAfterFinished: 120 # supprime le job après un ttl 2 minutes 
  template:
    spec:
      hostPID: true
      containers:
        - name: kube-bench
          image: docker.io/aquasec/kube-bench:latest
          command:
            [
              "kube-bench",
              "run",
              "--targets",
              "node,policies,managedservices",
              "--benchmark",
              "gke-1.6.0",
            ]
          volumeMounts:
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
            - name: home-kubernetes
              mountPath: /home/kubernetes
              readOnly: true
      restartPolicy: Never
      volumes:
        - name: var-lib-kubelet
          hostPath:
            path: "/var/lib/kubelet"
        - name: etc-systemd
          hostPath:
            path: "/etc/systemd"
        - name: etc-kubernetes
          hostPath:
            path: "/etc/kubernetes"
        - name: home-kubernetes
          hostPath:
            path: "/home/kubernetes"

 

• Configurer l'accès au cluster k8s et executer le job

kubectl -n kube-system apply -f job-gke.yaml

# attendre que le job termine
kubectl -n kube-system  wait --for=condition=complete "job/kube-bench" --timeout=300s

# recuperer les logs rapport
kubectl -n kube-system  logs job/kube-bench > cluster_name_kube_version.txt

 

• Analyse des résultats

kube-bench génère un rapport détaillé avec les remediations en indiquant les tests réussis, les échecs et les avertissements. Par exemple :

Import the policy file into Binary Authorization:
  gcloud container binauthz policy import <yaml_policy>

5.10.5 Enable security posture via the UI, gCloud or API.
https://cloud.google.com/kubernetes-engine/docs/how-to/protect-workload-configuration


== Summary managedservices ==
0 checks PASS
0 checks FAIL
34 checks WARN
0 checks INFO

== Summary total ==
11 checks PASS
2 checks FAIL
54 checks WARN
0 checks INFO

 

Les résultats vous permettent de savoir quels paramètres doivent être corrigés pour améliorer la sécurité de votre cluster.

Bonnes pratiques pour utiliser kube-bench

• Intégrez kube-bench dans votre pipeline CI/CD
  Automatisez les audits de sécurité en exécutant kube-bench dans le pipeline CI/CD pour détecter les problèmes avant le déploiement.

• Auditez régulièrement vos clusters
  La configuration de votre cluster peut évoluer au fil du temps. Planifiez des audits réguliers pour maintenir un niveau de sécurité optimal.

• Corrigez les problèmes identifiés
  Les résultats de kube-bench ne sont utiles que si vous agissez en conséquence. Utilisez les recommandations pour renforcer la sécurité de votre cluster.

• Combine kube-bench avec d'autres outils de sécurité
  kube-bench est un excellent point de départ, mais il est recommandé de le compléter avec d'autres outils comme trivy ou suse security (neuvector) pour le scan de cve et appliquer des policies.

 

Trivy Operator

Trivy Operator est un opérateur Kubernetes open source développé par Aqua Security. Il s'appuie sur Trivy, un scanner de vulnérabilités polyvalent, pour auditer en continu les ressources des clusters k8s:

• Vulnérabilités dans les images conteneurisées
  Il scanne les images déployées dans le cluster pour identifier les vulnérabilités connues (CVE).

• Configurations à risque
  Il vérifie les configurations de des ressources Kubernetes (pods, deployments, etc.) par rapport aux bonnes pratiques de sécurité.

• Secrets exposés
  Il détecte les secrets (mots de passe, tokens, clés API) accidentellement exposés dans les ressources.

Trivy Operator fonctionne en déployant des Custom Resource Definitions (CRDs) dans le cluster, ce qui lui permet de surveiller et de scanner les ressources de manière native.

Installation avec le registry OCI

Trivy Operator peut être installé via Helm en adaptant les vaules, ce qui simplifie son déploiement. Voici les étapes pour l'installer :

helm install trivy-operator oci://ghcr.io/aquasecurity/helm-charts/trivy-operator \
     --namespace trivy-system \
     --create-namespace \
     --version 0.25.0 \
     --set="trivy.ignoreUnfixed=true"

 

Utilisation

Une fois installé, Trivy Operator commence automatiquement à scanner les ressources du cluster. Vous pouvez consulter les résultats des scans en interrogeant les CRDs. Par exemple, pour voir les vulnérabilités détectées dans les images :

kubectl -n trivy-system get vulnerabilityreports -o wide

 

Pour voir les problèmes de configuration :

kubectl -n trivy-system get configauditreports -o wide

 

 

Bonnes pratiques pour utiliser Trivy Operator

• Scanner les images avant le déploiement
  Intégrez Trivy dans le pipeline CI/CD pour détecter les vulnérabilités avant que les images ne soient déployées.

• Auditer régulièrement votre cluster
  Planifiez des scans réguliers pour maintenir un niveau de sécurité optimal.

• Corriger les problèmes détectés
  Utilisez les rapports générés par Trivy Operator pour corriger les vulnérabilités et les configurations à risque.

• Combiner avec d'autres outils de sécurité
  Complétez Trivy Operator avec des outils comme kube-bench (pour les audits CIS).