Projets Kubernetes
Un projet Kubernetes est un ensemble d’images Docker appartenant à un espace de noms sur un cluster Kubernetes, le tout vu comme un unique actif agrégeant les vulnérabilités des images qui le composent. Chaque image est vue comme une technologie du projet, ce qui permet de connaitre les images vulnérables sans s’intéresser à leur contenu.
Création d’un projet Kubernetes
Les projets Kubernetes sont un type de connexion mode sans-agent. Les données à renseigner dépendent de la façon de se connecteur au cluster. Il est toujours possible de se connecter à un cluster en passant directement par l’API de Kubernetes, mais pour faciliter la gestion des identifiants, Cyberwatch peut récupérer automatiquement depuis Azure ou AWS les configurations Kubernetes.
Cluster Kubernetes
Pour accéder directement à un cluster Kubernetes, il faut tout d’abord lui créer un jeu d’identifiants enregistrés de type Kubernetes. Les identifiants créés doivent avoir les permissions RBAC suivantes :
- apiGroups: [""]
resources: ["namespaces/status", "pods/status"]
verbs: ["list", "get"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["list"]
Voir la documentation Kubernetes Using RBAC Authorization pour plus d’information.
Le cluster sera ensuite sélectionnable lors de la création du projet Kubernetes.
Le champ Adresse du projet doit contenir le nom de l’espaces de noms duquel lister les images, par exemple « mon namespace ». Dans le cas où d’autres clusters définiraient le même espace de nom, il est possible de le préfixer d’un nom arbitraire de cluster séparé par un slash, par exemple « mon cluster/mon namespace ». Le nom du cluster ainsi ajouté n’a aucun impact sur le résultat du scan.
Azure Kubernetes Service
Pour configurer un cluster AKS, une clé d’API Azure est requise. Le processus d’ajout d’identifiants enregistrés Azure est le même que pour les découvertes Azure.
Pour identifier un cluster AKS, 3 informations sont nécessaires :
- l’ID de l’abonnement auquel il est rattaché,
- le nom de son groupe de ressource, le cas échéant,
- le nom du cluster.
Sur la page de création de la connexion mode sans-agent, sélectionner le type projet Kubernetes et le jeu d’identifiant Azure fait apparaitre les champs spécifiques à Azure.
Le nom du cluster ne dispose pas d’un champ propre et doit être écrit dans l’adresse, suivi d’un slash puis du nom de l’espace de noms du projet, par exemple « mon cluster/mon namespace ».
Amazon Elastic Kubernetes Service
Pour configurer un cluster EKS, il faut une clé d’API AWS. Les étapes de configuration sont les mêmes que pour les découvertes Amazon Web Services.
À la création de la connexion mode sans-agent de type projet Kubernetes, le champ Adresse doit être de la forme « mon cluster/mon namespace » où « mon cluster » désigne le nom du cluster sur AWS, et où « mon namespace » désigne le nom de l’espace de noms sur le cluster Kubernetes.
En plus de l’adresse, il faut également renseigner dans le champ Région la zone géographique du cluster. Le Rôle permet optionnellement de renseigner un ARN sur lequel faire l’opération AssumeRole, si nécessaire.
Scan des images
Pour avoir les informations de vulnérabilités, les images des projets Kubernetes doivent être scannées en tant qu’images Docker enregistrées indépendamment.
Les projets Kubernetes remontent leurs images par digest, qui sert de clé pour retrouver les images scannées. Ces dernière doivent contenir une métadonnée IMAGE_DIGEST, déclarée de la forme META:IMAGE_DIGEST|sha256:…
dans une de leurs analyses. Le SHA-256 étant l’unique critère, l’image trouvée peut être un actif air gap comme une image Docker, peut provenir d’un registre miroir voire porter un nom différent. Pour plus de fiabilité il est préférable d’enregistrer les images par digest plutôt que par tag.
Pour tenir compte des nouvelles images Docker, le projet Kubernetes doit être réanalysé.
Enregistrement manuel
Les images manquantes d’un projet Kubernetes peuvent être ajoutées manuellement par digest depuis le menu Gestion des actifs > Images Docker de la barre latérale en précisant dans le champ Tag une version de la forme sha256:50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c
, par exemple.
Pour faciliter l’enregistrement manuel, il est aussi possible d’ouvrir l’onglet Technologies de la page de détails du projet Kubernetes et de cliquer sur l’icône d’ajout à droite de chaque image Docker absente.
Enregistrement automatique
L’approche la plus simple pour scanner toutes les images Docker d’un projet Kubernetes est de les enregistrer automatiquement à travers une découverte Docker, et plus précisément une découverte Kubernetes, AKS ou EKS dont le périmètre est défini à Images en cours d’exécution.
Dans le cas où les images proviendraient d’un registre Harbor, il est possible de configurer depuis l’administration, parmi les outils externes, un scanneur Harbor. Cette approche a l’avantage de faire scanner sans délai les nouvelles images Docker.
Découverte des projets
Les découvertes Docker pour Kubernetes, AKS et EKS proposent en Périmètre l’option Espaces de noms. Cette option a pour effet de lister les espaces de noms présents sur les pods au lieu de lister leurs images.
Les projets ainsi découverts peuvent être ajoutés manuellement comme actifs depuis la liste des actifs découverts en utilisant l’action groupée Scanner avec des connexions mode sans-agent, puis en sélectionnant comme type Projet Kubernetes.
L’enregistrement des nouveaux projets Kubernetes peut être automatisé depuis le formulaire d’édition de la découverte en activant l’enregistrement automatique en tant que connexions mode sans-agent de type Projet Kubernetes.