Référence des ports
Port 6443 (TCP) – Serveur d'API Kubernetes
Port sécurisé par défaut du serveur d'API Kubernetes (kube-apiserver), le plan de contrôle du cluster.
État par défaut
kube-apiserver sert du HTTPS sur 6443. Les clusters durcis exigent authentification et RBAC, mais ceux mal configurés autorisent l'accès anonyme ou accordent des rôles trop larges, exposant le contrôle total du cluster.
Attaques courantes
- Accès anonyme ou RBAC trop permissif menant à la prise de contrôle totale du cluster
- Lecture des Secrets, ConfigMaps et identifiants dans tous les namespaces
- Déploiement de pods malveillants pour exécuter du code sur les nœuds et pivoter en interne
- Pivotement vers l'API kubelet exposée sur 10250 pour l'exécution au niveau du nœud
Durcissement
- Désactiver l'authentification anonyme et appliquer un RBAC à moindre privilège
- Lier le serveur d'API à un réseau privé ; ne jamais exposer 6443 à Internet
- Exiger une authentification forte (certificats/OIDC) et la journalisation d'audit
- Restreindre l'API kubelet (10250) et utiliser des NetworkPolicies
- Maintenir Kubernetes à jour et faire tourner les identifiants
Commande nmap
nmap -p6443 --script ssl-cert,http-title <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Que tourne sur le port 6443 ?
Le port 6443 est le port sécurisé par défaut du serveur d'API Kubernetes
(kube-apiserver), le cœur du plan de contrôle. Chaque composant — kubectl, les
contrôleurs, les kubelets et les opérateurs — s'authentifie auprès du serveur
d'API via HTTPS sur 6443 pour lire et modifier l'état du cluster. C'est le point
de terminaison le plus sensible d'un cluster Kubernetes.
Pourquoi c'est important pour la sécurité
Quiconque contrôle le serveur d'API contrôle le cluster. Les déploiements durcis exigent authentification et RBAC, mais les clusters mal configurés autorisent l'accès anonyme ou accordent des rôles trop larges, laissant quiconque atteint 6443 lire les Secrets et identifiants, déployer des charges de travail et s'exécuter sur les nœuds. Combiné à une API kubelet exposée sur 10250, cela mène à la prise de contrôle complète du cluster et des hôtes.
Comment c'est attaqué
Les attaquants scannent les ports 6443 ouverts et testent l'accès anonyme ou un RBAC faible. Avec le moindre point d'ancrage, ils vident les Secrets et ConfigMaps de tous les namespaces, récoltent des identifiants et déploient des pods malveillants pour exécuter du code sur les nœuds. De là, ils pivotent vers l'API kubelet (10250) pour l'exécution au niveau du nœud et se déplacent latéralement dans le cluster et les comptes cloud connectés.
Liste de durcissement
Désactivez l'authentification anonyme et appliquez un RBAC à moindre privilège, en auditant les liaisons de rôles. Liez le serveur d'API à un réseau privé et gardez 6443 hors d'Internet. Exigez une authentification forte (certificats clients ou OIDC), activez la journalisation d'audit, restreignez l'API kubelet (10250) et appliquez des NetworkPolicies. Maintenez Kubernetes à jour et faites tourner les identifiants. Utilisez l'extrait nmap ci-dessus pour vérifier l'exposition sur les clusters que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- Est-il sûr d'exposer le serveur d'API Kubernetes sur le port 6443 ?
- Non. Si l'authentification anonyme est activée ou si le RBAC est trop large, quiconque atteint 6443 peut prendre le contrôle du cluster. Désactivez l'accès anonyme, appliquez un RBAC à moindre privilège et gardez le serveur d'API sur un réseau privé.
- Que se passe-t-il si le RBAC Kubernetes est mal configuré ?
- Des rôles trop permissifs laissent les attaquants lire les Secrets, déployer des pods et s'exécuter sur les nœuds — soit une compromission totale du cluster. Appliquez le moindre privilège, auditez les liaisons et restreignez l'API kubelet sur 10250.