Objectifs du chapitre et prérequis

Dans le monde informatique, la sécurité est devenue un aspect incontournable. En effet, un système qui n’est pas à jour ou qui contient des brèches de sécurité peut vite faire l’objet d’attaques particulièrement gênantes (surtout en cas d’exposition sur Internet).

Le but de ce chapitre est de présenter les outils Trivy et Gatekeeper. Le premier permet par exemple d’analyser les images associées aux applications démarrées dans un cluster tandis que le second permet d’imposer des règles : réduction des droits utilisés par les applications, utilisation de limites de consommation de ressources, respect de normes de nommage, etc.

Trivy : analyse de failles de sécurité

1. Trivy : outil d’analyse du cluster

a. Présentation de Trivy

Trivy est à l’origine un outil d’analyse d’images de conteneurs (il est présenté dans le chapitre Compilation et stockage d’images Docker). Il peut également servir comme un outil d’analyse d’un cluster Kubernetes. Le projet est hébergé sur GitHub à l’adresse suivante : https://github.com/aquasecurity/trivy

Pour mémoire, le projet Kube Hunter de la même société poursuivait le même but mais n’est plus maintenu.

b. Installation de Trivy

Trivy est écrit en Go : il se présente sous la forme d’un binaire autoporteur compressé dans une archive.

Cette dernière se récupère à l’emplacement suivant : https://github.com/aquasecurity/trivy/releases

En alternative, il est possible d’installer cet outil à l’aide d’Arkade :

$ arkade get trivy

Lancez-le avec l’option version afin de vérifier que tout fonctionne correctement :

$ trivy version

La commande doit renvoyer la version de Trivy ainsi que les versions des dépendances utilisées : base de données de vulnérabilités, librairie Java, etc.

c. Lancement de l’analyse

L’analyse d’un cluster Kubernetes à l’aide de Trivy se fait à l’aide des paramètres suivants :

le mot kubernetes (ou son raccourci k8s) ;
l’option --report suivie du mot-clé summary ;
enfin l’option --timeout suivie d’une durée d’analyse maximum.

Ci-dessous, un exemple de lancement avec un temps d’analyse maximum de 20 minutes :

$ trivy k8s --report summary --timeout 20m

L’analyse est relativement longue et dure plus de 5 minutes.

Ci-dessous un extrait de résultat d’analyse :

... INFO    Node scanning is enabled 
... INFO    If you want to disable Node scanning via an in-cluster Job, 
please try '--disable-node-collector' to disable the Node-Collector job. 
441 / 441 [-------------------] 100.00% 1 p/s 
...  
 
Summary Report for minikube 
 
 
Workload Assessment 
... ─────────────────────...

OPA (Open Policy Agent) Gatekeeper : le gardien du cluster

1. Présentation d’OPA Gatekeeper

L’outil Trivy est en place et vérifie régulièrement que les configurations existantes respectent les bonnes pratiques ou encore que les images utilisées n’introduisent pas des failles de sécurité connues. En revanche, rien n’est fait pour vérifier les changements appliqués au système.

OPA Gatekeeper est là pour vérifier l’intégrité des éléments du système avant leur déploiement. Il permet de s’assurer de l’application de bonnes pratiques : lancement de pods avec limites, restriction des privilèges système, etc. Il peut aussi contraindre l’utilisation de règles propres à une entité : utilisation de registres internes, respect des normes de nommage, présence de labels obligatoires sur les ressources, etc.

L’outil peut aussi appliquer des règles de sécurité automatiquement. Pour des raisons de simplicité, seule la vérification sera abordée.

2. Installation de Gatekeeper

Avant toute chose, il est nécessaire d’installer le composant Gatekeeper. Comme d’habitude, ce dernier est disponible sous la forme d’un chart Helm.

Ajoutez tout d’abord la source du chart Helm à l’aide des instructions suivantes :

$ helm repo add gatekeeper \ 
        https://open-policy-agent.github.io/gatekeeper/charts

Procédez ensuite à l’installation de l’instance gatekeeper dans un espace de noms dédié du chart gatekeeper/gatekeeper :

$ helm upgrade --install gatekeeper gatekeeper/gatekeeper \ 
        --namespace gatekeeper --create-namespace

Vérifiez ensuite l’état du pod associé à Gatekeeper :

$ kubectl -n gatekeeper get pods

Ci-dessous, un exemple d’état une fois le composant correctement démarré :

NAME                                      READY STATUS   RESTARTS AGE 
gatekeeper-audit-78cdfcc9f9-g7dgr...

Analyse et sécurisation d’un cluster