Référence des ports
Port 2379 (TCP) – etcd Client API
Port API client par défaut d'etcd, le magasin clé-valeur distribué derrière Kubernetes.
État par défaut
etcd peut être configuré pour écouter sur 0.0.0.0:2379 sans authentification par certificat client. Les clusters mal configurés exposent l'intégralité du magasin clé-valeur, y compris chaque secret Kubernetes, à quiconque atteint le port.
Attaques courantes
- Lectures non authentifiées qui extraient tous les secrets et l'état du cluster Kubernetes
- Compromission totale du cluster en extrayant les jetons de compte de service et les identifiants
- Altération de l'état du cluster par écriture de clés arbitraires
- Divulgation d'informations sur les configmaps, certificats et la topologie
Durcissement
- Lier à localhost ou à une interface privée ; ne jamais exposer 2379 à Internet
- Exiger l'authentification par certificat client et pair (TLS mutuel)
- Activer le RBAC et le chiffrement au repos des données etcd
- Filtrer 2379 vers les nœuds du plan de contrôle et le serveur API Kubernetes (6443) uniquement
- Maintenir etcd à jour et auditer les accès
Commande nmap
nmap -p2379 --script http-title <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Que tourne sur le port 2379 ?
Le port 2379 est le port API client par défaut d'etcd, le magasin clé-valeur distribué qui alimente Kubernetes. Le serveur API et les autres clients lisent et écrivent l'état du cluster via 2379, tandis que le trafic entre les membres etcd utilise 2380. etcd détient la copie de référence de tout ce que le cluster connaît.
Pourquoi c'est important pour la sécurité
etcd stocke tout l'état de Kubernetes, y compris chaque secret, jeton de compte de service et certificat. Si 2379 est accessible sans authentification par certificat client, quiconque se connecte peut lire l'intégralité du magasin. C'est de fait une compromission totale du cluster : les jetons extraits permettent à un attaquant de prendre le contrôle du serveur API Kubernetes sur 6443 et des charges de travail qui en dépendent.
Comment c'est attaqué
Les attaquants scannent les ports 2379 ouverts et émettent des lectures non authentifiées pour extraire toutes les clés, récoltant secrets et identifiants. Ils peuvent aussi écrire des clés arbitraires pour altérer l'état du cluster, injecter de la configuration ou élever leurs privilèges sur l'ensemble du cluster.
Liste de durcissement
Liez etcd à localhost ou à une interface privée et gardez 2379 hors d'Internet. Exigez le TLS mutuel avec certificats client et pair, activez le RBAC et le chiffrement au repos, et filtrez 2379 pour que seuls les nœuds du plan de contrôle et le serveur API (6443) puissent l'atteindre. Appliquez les correctifs régulièrement et auditez les accès. Utilisez l'extrait nmap ci-dessus pour détecter les instances exposées sur les hôtes que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- Pourquoi un port etcd exposé est-il si dangereux ?
- etcd stocke tout l'état de Kubernetes, y compris chaque secret et jeton de compte de service. Un accès en lecture non authentifié à 2379 signifie une compromission totale du cluster : un attaquant peut extraire les identifiants et prendre le contrôle de l'API Kubernetes sur 6443.
- Comment protéger etcd ?
- Liez à une interface privée, exigez le TLS mutuel avec certificats client, activez le RBAC et le chiffrement au repos, et filtrez 2379 pour que seuls les nœuds du plan de contrôle et le serveur API puissent l'atteindre.