Communication entre les nœuds et le plan de contrôle

Ce document répertorie les chemins de communication entre le serveur API et le cluster Kubernetes. L'objectif est de permettre aux utilisateurs de personnaliser leur installation pour renforcer la configuration réseau afin que le cluster puisse fonctionner sur un réseau non fiable (ou sur des adresses IP publiques complètement) fournies par un fournisseur de cloud.

Nœud vers le plan de contrôle

Kubernetes utilise un modèle d'API de type "hub-et-spoke". Toutes les utilisations de l'API à partir des nœuds (ou des pods qu'ils exécutent) se terminent au niveau du serveur API. Aucun des autres composants du plan de contrôle n'est conçu pour exposer des services distants. Le serveur API est configuré pour écouter les connexions distantes sur un port HTTPS sécurisé (généralement le port 443) avec une ou plusieurs formes d'authentification client activées. Une ou plusieurs formes d'autorisation devraient être activées, en particulier si les requêtes anonymes ou les jetons de compte de service sont autorisés.

Les nœuds doivent être provisionnés avec le certificat racine public pour le cluster afin qu'ils puissent se connecter de manière sécurisée au serveur API avec des informations d'identification client valides. Une bonne approche consiste à ce que les informations d'identification client fournies au kubelet soient sous la forme d'un certificat client. Consultez l'amorçage TLS du kubelet pour la provision automatisée des certificats client du kubelet.

Les pods qui souhaitent se connecter au serveur API peuvent le faire de manière sécurisée en utilisant un compte de service de sorte que Kubernetes injecte automatiquement le certificat racine public et un jeton d'accès valide dans le pod lors de son instanciation. Le service kubernetes (dans le namespace default) est configuré avec une adresse IP virtuelle qui est redirigée (via kube-proxy) vers le point de terminaison HTTPS du serveur API.

Les composants du plan de contrôle communiquent également avec le serveur API via le port sécurisé.

Par conséquent, le mode de fonctionnement par défaut des connexions des nœuds et des pods exécutés sur les nœuds vers le plan de contrôle est sécurisé par défaut et peut fonctionner sur des réseaux non fiables et/ou publics.

Plan de contrôle vers le nœud

Il existe deux chemins de communication principaux du plan de contrôle (le serveur API) vers les nœuds. Le premier est du serveur API au processus kubelet qui s'exécute sur chaque nœud du cluster. Le deuxième est du serveur API vers n'importe quel nœud, pod ou service via la fonctionnalité de proxy du serveur API.

Serveur API vers kubelet

Les connexions du serveur API au kubelet sont utilisées pour :

  • Récupérer les journaux des pods.
  • Se connecter (généralement via kubectl) aux pods en cours d'exécution.
  • Fournir la fonctionnalité de transfert de port du kubelet.

Ces connexions se terminent au niveau du point de terminaison HTTPS du kubelet. Par défaut, le serveur API ne vérifie pas le certificat de service du kubelet, ce qui rend la connexion vulnérable aux attaques de l'homme du milieu et non sécurisée pour une utilisation sur des réseaux non fiables et/ou publics.

Pour vérifier cette connexion, utilisez le paramètre --kubelet-certificate-authority pour fournir au serveur API un ensemble de certificats racine à utiliser pour vérifier le certificat de service du kubelet.

Si cela n'est pas possible, utilisez le tunnel SSH entre le serveur API et le kubelet si nécessaire pour éviter de se connecter via un réseau non fiable ou public.

Enfin, l'authentification et/ou l'autorisation du kubelet devraient être activées pour sécuriser l'API du kubelet.

Serveur API vers les nœuds, les pods et les services

Les connexions du serveur API vers un nœud, un pod ou un service sont par défaut des connexions HTTP non sécurisées et ne sont donc ni authentifiées ni chiffrées. Elles peuvent être exécutées via une connexion HTTPS sécurisée en préfixant https: au nom du nœud, du pod ou du service dans l'URL de l'API, mais elles ne vérifieront pas le certificat fourni par le point de terminaison HTTPS ni ne fourniront des informations d'identification client. Ainsi, bien que la connexion soit chiffrée, elle ne garantira aucune intégrité. Ces connexions ne sont actuellement pas sûres pour une utilisation sur des réseaux non fiables ou publics.

Tunnels SSH

Kubernetes prend en charge les tunnels SSH pour protéger les chemins de communication du plan de contrôle vers les nœuds. Dans cette configuration, le serveur API initie un tunnel SSH vers chaque nœud du cluster (en se connectant à le serveur SSH qui écoute sur le port 22) et fait passer tout le trafic destiné à un kubelet, un nœud, un pod ou un service à travers le tunnel. Ce tunnel garantit que le trafic n'est pas exposé en dehors du réseau dans lequel les nœuds sont exécutés.

Service Konnectivity

FEATURE STATE: Kubernetes v1.18 [beta]

En remplacement des tunnels SSH, le service Konnectivity fournit un proxy de niveau TCP pour la communication entre le plan de contrôle et le cluster. Le service Konnectivity se compose de deux parties : le serveur Konnectivity dans le réseau du plan de contrôle et les agents Konnectivity dans le réseau des nœuds. Les agents Konnectivity initient des connexions vers le serveur Konnectivity et maintiennent les connexions réseau. Après avoir activé le service Konnectivity, tout le trafic du plan de contrôle vers les nœuds passe par ces connexions.

Suivez la tâche du service Konnectivity pour configurer le service Konnectivity dans votre cluster.

A suivre

Dernière modification September 12, 2024 at 5:58 PM PST: Update French documentation for architecture concepts (ecaea1a7cb)