Connecter un cluster Kubernetes

Ctadel lit vos clusters Kubernetes par leur API, sans agent dans le cluster : il ne fait que lister et lire des objets. L’identité qu’il utilise dépend du cloud et n’est pas toujours limitée à la lecture ; voir le cas EKS et les limites ci-dessous. Un cluster managé est découvert par le compte cloud qui le porte ; tout autre cluster se connecte en fournissant un kubeconfig.

Deux façons de connecter un cluster

Un kubeconfig fourni prend le pas sur les identifiants du compte cloud, y compris pour un cluster managé déjà découvert.

Clusters découverts par un compte cloud

Les clusters apparaissent dans « Paramètres », onglet « Intégrations », sous-onglet « Kubernetes » dès que l’inventaire du compte cloud les a lus. Pour chacun, Ctadel construit un kubeconfig temporaire à partir de l’API du cloud ; ce kubeconfig n’est pas conservé.

Un cluster en cours de création ou de suppression répond avec un kubeconfig incomplet ; le scan échoue proprement et reprend à l’inventaire suivant.

Le cas EKS et le groupe ctadel-scanner

Sur EKS, obtenir un kubeconfig ne suffit pas : le cluster doit accepter l’identité IAM de Ctadel. Deux chemins existent.

Chemin par défaut. Le gabarit CloudFormation du rôle Ctadel porte l’option EnableKubernetesAccess, à true par défaut. Elle accorde eks:CreateAccessEntry, eks:DescribeAccessEntry et eks:AssociateAccessPolicy. Au premier scan, Ctadel enregistre sa propre identité comme access entry du cluster et lui associe la politique AmazonEKSClusterAdminPolicy. Ce chemin ne fonctionne que sur les clusters en mode d’authentification API ou API_AND_CONFIG_MAP.

Chemin recommandé. Passez EnableKubernetesAccess à false et accordez l’accès vous-même avec un rôle en lecture seule. C’est ce que propose le bouton « Instructions », affiché sur un cluster EKS en état « Configuration requise » :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ctadel-scanner
rules:
  - apiGroups: [""]
    resources: [pods, nodes, namespaces, services, serviceaccounts, secrets, configmaps, limitranges, resourcequotas, persistentvolumes, persistentvolumeclaims]
    verbs: [get, list]
  - apiGroups: [apps]
    resources: [deployments, daemonsets, statefulsets, replicasets]
    verbs: [get, list]
  - apiGroups: [batch]
    resources: [cronjobs, jobs]
    verbs: [get, list]
  - apiGroups: [networking.k8s.io]
    resources: [ingresses, networkpolicies]
    verbs: [get, list]
  - apiGroups: [rbac.authorization.k8s.io]
    resources: [roles, rolebindings, clusterroles, clusterrolebindings]
    verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ctadel-scanner
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ctadel-scanner
subjects:
  - kind: Group
    name: ctadel-scanner
    apiGroup: rbac.authorization.k8s.io

Puis rattachez l’identité IAM de Ctadel à ce groupe. L’ARN à utiliser figure sous « Détails de l’erreur : » dans le même dialogue.

Clusters en mode API ou API_AND_CONFIG_MAP (le défaut) :

aws eks create-access-entry --cluster-name <CLUSTER> --principal-arn <IAM_ARN> --kubernetes-groups ctadel-scanner

Clusters restés en mode CONFIG_MAP, dans le ConfigMap aws-auth de kube-system, sous mapRoles ou mapUsers :

- rolearn: <IAM_ARN>
  username: ctadel-scanner
  groups:
    - ctadel-scanner

Une fois l’accès accordé, cliquez sur « Rescanner » sur ce cluster.

Connecter un cluster par kubeconfig

1. Ouvrez « Paramètres », onglet « Intégrations », sous-onglet « Kubernetes ».
2. Cliquez sur « Connecter un cluster ». Pour un cluster déjà découvert, utilisez plutôt « Connecter avec un kubeconfig » sur sa ligne : son identifiant est conservé et ses constats restent sur une seule entrée.
3. Renseignez « Nom du cluster », au besoin « Identifiant du cluster (optionnel) » et « Région (optionnel) », puis choisissez le « Fournisseur cloud ».
4. Collez le contenu dans « Kubeconfig ». La commande kubectl config view --raw --minify donne le contexte courant avec ses données en ligne.
5. Cliquez sur « Connecter le cluster », puis sur « Scanner maintenant ».

Le kubeconfig est chiffré (AES-256-GCM) avant d’être écrit dans la base de votre instance. « Déconnecter » l’efface.

L’identité portée par le kubeconfig doit avoir les droits du rôle ctadel-scanner ci-dessus, par exemple un compte de service lié à ce ClusterRole, et rien de plus.

Ce qu’un kubeconfig ne peut pas contenir

Le kubeconfig est vérifié à la saisie, puis à chaque scan. Tout ce qui ferait exécuter une commande ou lire un fichier sur votre instance Ctadel est refusé.

Le fichier doit définir au moins un cluster et un utilisateur. Un kubeconfig refusé l’est au moment de la saisie, avec le champ en cause dans le message.

Ce que le scanner lit

Le scanner Kubernetes ne fait que get et list sur les objets du rôle ci-dessus : pods, nœuds, espaces de noms, services, comptes de service, secrets, ConfigMaps, LimitRanges, ResourceQuotas, volumes persistants et leurs demandes, Deployments, DaemonSets, StatefulSets, ReplicaSets, CronJobs, Jobs, Ingresses, NetworkPolicies, et l’ensemble des rôles et liaisons RBAC. Les secrets servent aux contrôles qui les concernent et à la lecture des identifiants de registre des pods (imagePullSecrets) ; ces identifiants ne quittent pas le scanner Kubernetes et ne sont pas conservés après le scan.

Les images des pods

Après la passe de configuration, chaque image distincte trouvée dans les pods est analysée (paquets, vulnérabilités, secrets dans les couches), avec une limite de quatre minutes par image. Pour tirer les images privées, le scanner Kubernetes assemble pour la durée du scan des identifiants de registre, effacés ensuite, composés :

• des imagePullSecrets des pods (types dockerconfigjson et dockercfg) ;
• des identifiants du compte cloud pour son registre, quand aucun secret ne couvre l’hôte : jeton ECR (AWS), client ID et secret du service principal sur ACR (Azure, qui demande le rôle AcrPull), clé du compte de service sur Artifact Registry et Container Registry (Google Cloud), clé secrète sur le registre Scaleway.

Une image qui ne peut pas être tirée est comptée et nommée dans le résultat ; elle n’apporte aucun paquet et ne doit pas se lire comme une image saine.

Suivre l’état d’un cluster

Chaque ligne porte un état : « Non scanné », « Scan en cours... », « Connecté », « Configuration requise » ou « Erreur », avec le message d’erreur le cas échéant. La liste se rafraîchit d’elle-même tant qu’un scan est en cours. « Configuration requise » couvre les refus d’autorisation du cluster, l’échec de l’inscription de l’access entry EKS, les clusters EKS en mode CONFIG_MAP et un secret de service principal Azure refusé ; le reste est « Erreur ».

Limites

• La liste « Fournisseur cloud » du dialogue de connexion propose AWS, Scaleway, GCP, Azure et « Other / On-premise » ; pour un cluster OVHcloud MKS ou OUTSCALE OKS connecté par kubeconfig, choisissez « Other / On-premise », ou connectez-le depuis sa ligne s’il a été découvert.
• Un cluster connecté uniquement par kubeconfig, sans compte cloud derrière, n’est pas repris par l’inventaire automatique. Relancez-le avec « Rescanner ».
• Sur EKS, avec l’option EnableKubernetesAccess laissée à true, l’identité de Ctadel reçoit la politique AmazonEKSClusterAdminPolicy du cluster, et non un rôle en lecture seule. Passez l’option à false et appliquez le rôle ctadel-scanner pour limiter les droits.
• Sur AKS, Ctadel demande le kubeconfig administrateur du cluster (listClusterAdminCredential) ; le service principal doit y être autorisé.
• Le serveur d’API doit être joignable depuis votre instance Ctadel : aucun proxy ni tunnel n’est accepté dans le kubeconfig.
• Une image dont l’analyse dépasse quatre minutes, ou dont la référence n’est pas une référence d’image plausible, est marquée en échec, sans paquet.
• Les clusters EKS en mode CONFIG_MAP exigent la modification manuelle du ConfigMap aws-auth.
• La détection d’événements à l’exécution dans les clusters est en validation interne, non disponible pour les clients.