Découvertes Docker

Les découvertes Docker permettent de lister un ensemble d’images Docker à partir d’un registre ou encore d’un déploiement existant. Les images Docker découvertes peuvent ensuite être ajoutées par une action groupée à Cyberwatch afin d’être scannées.

Kubernetes via kubeconfig

Prérequis

Les découvertes Kubernetes via kubeconfig requièrent :

  • Le fichier kubeconfig des clusters à scanner, dont l’authentification Microsoft Entra est déléguée à kubelogin
  • Sur chaque cluster à scanner, le droit de lister les pods (droit Lecteur RBAC Azure Kubernetes Service)
  • Les prérequis propres au mode d’authentification retenu, détaillés dans la section correspondante ci-dessous

La découverte Kubernetes via kubeconfig scanne les clusters Kubernetes décrits dans un fichier kubeconfig afin de lister toutes les images Docker qui y sont déployées. Les modes d’authentification actuellement pris en charge ciblent les clusters AKS authentifiés via Microsoft Entra.

Cette découverte est complémentaire de la découverte AKS : elle s’adresse en particulier aux clusters dont l’audience Microsoft Entra est personnalisée (un server-id propre à votre inscription d’application, au lieu de l’audience AKS par défaut), que la découverte AKS standard ne peut pas atteindre. Le server-id étant lu directement dans le fichier kubeconfig, cette découverte fonctionne quelle que soit l’audience configurée sur le cluster.

La découverte requiert un jeu d’identifiants de type Fichier kubeconfig, que vous pouvez créer depuis le menu Identifiants enregistrés. Il suffit de coller le contenu de votre fichier kubeconfig (qui doit contenir les sections clusters, contexts et users), puis de choisir le Mode d’authentification correspondant à la méthode déclarée dans le fichier kubeconfig pour s’authentifier auprès de vos clusters.

Cyberwatch parcourt l’ensemble des contextes définis dans le fichier kubeconfig et scanne chaque cluster auquel il parvient à s’authentifier. Un contexte qui correspond à un autre mode d’authentification ou à un autre identifiant que celui configuré est ignoré, sans interrompre le scan des autres contextes.

Les fichiers kubeconfig générés pour AKS délèguent l’authentification au binaire kubelogin. Cyberwatch n’exécute pas ce binaire : il lit le mode d’authentification et ses paramètres (notamment le server-id) directement dans le fichier, puis obtient le jeton auprès de Microsoft Entra. Aucune installation de kubelogin n’est donc nécessaire côté Cyberwatch.

AKS — Service Principal

Prérequis

  • Un jeu d’identifiants Microsoft Azure de type principal de service, créé comme pour les découvertes Azure, dont l’ID d’application (de client) et l’ID de locataire correspondent à ceux indiqués dans le fichier kubeconfig

Ce mode convient aux fichiers kubeconfig dont l’utilisateur s’authentifie via un principal de service (Service Principal), c’est-à-dire dont la commande kubelogin est de la forme ... --login spn. Le jeton d’accès au cluster est obtenu à partir de ce jeu d’identifiants, qui sert d’identifiant parent au fichier kubeconfig. Ce fichier s’obtient ainsi :

az aks get-credentials --resource-group <resource-group> --name <cluster-name>
kubelogin convert-kubeconfig -l spn

À la création de l’identifiant Fichier kubeconfig, choisir le mode AKS — Service Principal, puis sélectionner le jeu d’identifiants Microsoft Azure dans le champ Identifiant Azure.

AKS — Identité de charge de travail

Prérequis

Ce mode convient aux fichiers kubeconfig dont l’utilisateur s’authentifie via l’identité de charge de travail (Workload Identity) Microsoft Entra, c’est-à-dire dont la commande kubelogin est de la forme ... --login workloadidentity. Aucun secret ni identifiant parent n’est nécessaire : Cyberwatch s’authentifie à l’aide de l’identité fédérée de ses propres pods. Ce fichier s’obtient ainsi :

az aks get-credentials --resource-group <resource-group> --name <cluster-name>
kubelogin convert-kubeconfig -l workloadidentity

À la création de l’identifiant Fichier kubeconfig, choisir le mode AKS — Identité de charge de travail. Aucun identifiant parent n’est requis : les paramètres d’authentification sont dérivés de l’environnement du pod.

Si le déploiement Cyberwatch n’est pas configuré en identité de charge de travail, ce mode ne peut pas être utilisé : les contextes concernés seront ignorés et signalés comme tels dans le résultat de la découverte.

Créer la découverte

Une fois le jeu d’identifiants prêt, vous pourrez créer la découverte depuis le menu Découvertes, en cliquant sur le bouton Ajouter puis sur Kubernetes via kubeconfig dans la partie Images Docker.

Ajouter les images Docker découvertes

Depuis la liste des actifs découverts, vous pourrez voir et filtrer les images qui n’ont pas d’actifs associés. Pour les ajouter à Cyberwatch, vous pouvez sélectionner celles que vous souhaitez scanner et cliquer sur Actions groupées > Scanner comme images Docker.

L’ajout d’images Docker nouvellement découvertes à Cyberwatch peut être automatisé en activant l’enregistrement automatique depuis le formulaire d’édition de la découverte.

Le registre est automatiquement choisi à partir du nom de l’image découverte. Par exemple, une image example.com/library/hello utilisera automatiquement le registre Docker example.com, à condition cependant qu’il ait été ajouté en tant qu’identifiant enregistré. Si le registre est nouveau, un identifiant enregistré sera automatiquement créé et pourra être manuellement édité par la suite si une authentification est requise. Il est parfois possible d’indiquer un registre de préférence, mais il ne sera utilisé que pour les images découvertes dont le registre figurant dans le nom correspond avec le point d’entrée du registre.

Retour en haut

English Français Español