Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Communication avec les clusters d’utilisateurs en aval

Cette section décrit comment Rancher provisionne et gère les clusters d’utilisateurs en aval qui exécutent vos applications et services.

Le diagramme ci-dessous montre comment les contrôleurs de cluster, les agents de cluster et l’agent système Rancher permettent à Rancher de contrôler les clusters en aval.

Figure 1. Communication avec les clusters en aval

Les descriptions suivantes correspondent aux numéros dans le diagramme ci-dessus :

Le proxy d’authentification
Contrôleurs de Cluster et Agents de Cluster
Agent Système Rancher
Point de terminaison de cluster autorisé

1. Le proxy d’authentification

Dans ce diagramme, un utilisateur nommé Bob souhaite voir tous les pods en cours d’exécution sur un cluster utilisateur en aval appelé Cluster utilisateur 1. Depuis Rancher, il peut exécuter une commande kubectl pour voir les pods. Bob est authentifié via le proxy d’authentification de Rancher.

Le proxy d’authentification transmet tous les appels API Kubernetes aux clusters en aval. Il s’intègre avec des services d’authentification tels que l’authentification locale, Active Directory et GitHub. Pour chaque appel API Kubernetes, le proxy d’authentification authentifie l’appelant et définit les en-têtes d’imitation Kubernetes appropriés avant de transmettre l’appel aux maîtres Kubernetes.

Rancher communique avec les clusters Kubernetes en utilisant un compte de service. Chaque compte utilisateur dans Rancher correspond à un compte de service équivalent dans le cluster en aval. Rancher utilise le compte de service pour imiter l’utilisateur, ce qui fournit toutes les autorisations que l’utilisateur est censé avoir.

Par défaut, Rancher génère un fichier kubeconfig qui contient des informations d’identification pour le proxy à travers le serveur Rancher afin de se connecter au serveur API Kubernetes sur un cluster utilisateur en aval. Le fichier kubeconfig (kube_config_rancher-cluster.yml) contient un accès complet au cluster.

2. Contrôleurs de cluster et agents de cluster

Chaque cluster utilisateur en aval a un agent de cluster, qui ouvre un tunnel vers le contrôleur de cluster correspondant au sein du serveur Rancher.

Il y a un contrôleur de cluster et un agent de cluster pour chaque cluster en aval. Chaque contrôleur de cluster :

Surveille les changements de ressources dans le cluster en aval
Amène l’état actuel du cluster en aval à l’état souhaité
Configure les politiques de contrôle d’accès aux clusters et aux projets
Provisionne des clusters en appelant les pilotes de machine Docker et les moteurs Kubernetes requis, tels que GKE

Par défaut, pour permettre à Rancher de communiquer avec un cluster en aval, le contrôleur de cluster se connecte à l’agent de cluster. Si l’agent de cluster n’est pas disponible, le contrôleur de cluster peut se connecter à un agent système Rancher à la place.

L’agent de cluster, également appelé cattle-cluster-agent, est un composant qui s’exécute dans un cluster utilisateur en aval. Il effectue les tâches suivantes :

Se connecte à l’API Kubernetes des clusters Kubernetes lancés par Rancher
Gère les charges de travail, la création et le déploiement de pods dans chaque cluster
Applique les rôles et les liaisons définis dans les politiques globales de chaque cluster
Communique entre le cluster et le serveur Rancher (via un tunnel vers le contrôleur de cluster) au sujet des événements, des statistiques, des informations sur les nœuds et de la santé

3. Agent système Rancher

Si l’agent de cluster (également appelé cattle-cluster-agent) n’est pas disponible, l’agent système Rancher crée un tunnel vers le contrôleur de cluster pour communiquer avec Rancher.

Le rancher-system-agent s’exécute sur chaque nœud des clusters Kubernetes RKE2 et K3s. Il est utilisé pour interagir avec les nœuds lors de l’exécution des opérations de cluster. Des exemples d’opérations de cluster incluent la mise à niveau de la version de Kubernetes et la création ou la restauration d’instantanés etcd.

4. Point de terminaison de cluster autorisé

Un point de terminaison de cluster autorisé (ACE) permet aux utilisateurs de se connecter au serveur API Kubernetes d’un cluster en aval sans avoir à acheminer leurs demandes via le proxy d’authentification Rancher.

L’ACE est disponible sur les clusters RKE2 et K3s qui sont provisionnés ou enregistrés avec Rancher. Il n’est pas disponible sur les clusters d’un fournisseur Kubernetes hébergé, tel que l’EKS d’Amazon.

Il y a deux raisons principales pour lesquelles un utilisateur pourrait avoir besoin du point de terminaison de cluster autorisé :

Pour accéder à un cluster utilisateur en aval pendant que Rancher est hors service
Pour réduire la latence dans les situations où le serveur Rancher et le cluster en aval sont séparés par une longue distance

Le microservice kube-api-auth est déployé pour fournir la fonctionnalité d’authentification des utilisateurs pour le point de terminaison de cluster autorisé. Lorsque vous accédez au cluster utilisateur en utilisant kubectl, le serveur API Kubernetes du cluster vous authentifie en utilisant le service kube-api-auth comme webhook.

Comme le point de terminaison de cluster autorisé, le service d’authentification kube-api-auth est également uniquement disponible pour les clusters Kubernetes lancés par Rancher.

Exemple de scénario: Disons que le serveur Rancher est situé aux États-Unis, et que le Cluster Utilisateur 1 est situé en Australie. Un utilisateur, Alice, vit également en Australie. Alice peut manipuler des ressources dans le Cluster Utilisateur 1 en utilisant l’interface utilisateur de Rancher, mais ses demandes devront être envoyées d’Australie au serveur Rancher aux États-Unis, puis être renvoyées en Australie, où se trouve le cluster utilisateur en aval. La distance géographique peut entraîner une latence significative, que Alice peut réduire en utilisant le point de terminaison de cluster autorisé.

Avec ce point de terminaison activé pour le cluster en aval, Rancher génère un contexte Kubernetes supplémentaire dans le fichier kubeconfig afin de se connecter directement au cluster. Ce fichier contient les identifiants pour kubectl et helm.

Pour utiliser le contexte ACE dans votre kubeconfig, exécutez kubectl use-context <ace context name> après l’avoir activé.

Pour plus d’informations, reportez-vous à la section sur l’accès à votre cluster avec kubectl et le fichier kubeconfig.

Nous recommandons d’exporter le fichier kubeconfig afin que si Rancher tombe en panne, vous puissiez toujours utiliser les identifiants dans le fichier pour accéder à votre cluster.

Imitation

Les utilisateurs existent techniquement uniquement sur le cluster en amont. Rancher crée RoleBindings et ClusterRoleBindings qui font référence aux utilisateurs de Rancher, même s’il n’y a aucune ressource Utilisateur réelle sur le cluster en aval.

Lorsque les utilisateurs interagissent avec un cluster en aval via le proxy d’authentification, il doit y avoir une entité en aval pour servir d’acteur pour ces demandes. Rancher crée des comptes de service pour être cette entité. Chaque compte de service n’a qu’une seule autorisation, qui est de imiter l’utilisateur auquel il appartient. S’il n’y avait qu’un seul compte de service pouvant imiter n’importe quel utilisateur, il serait alors possible pour un utilisateur malveillant de corrompre ce compte et d’escalader ses privilèges en imitant un autre utilisateur. Ce problème a été à l’origine d’un CVE.

Dépannage de l’usurpation d’identité

Sur le cluster en aval, cinq ressources gèrent l’imitation :

espace de noms : cattle-impersonation-system
compte de service : cattle-impersonation-system/cattle-impersonation-<user ID>
secret de jeton de compte : cattle-impersonation-system/cattle-impersonation-<user ID>-token-<hash>
rôle de cluster : cattle-impersonation-<user ID>
liaison de rôle de cluster : cattle-impersonation-<user ID>

Dans cet exemple d’un rôle de cluster d’imitation typique, le système est configuré pour utiliser github comme fournisseur d’authentification :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 creationTimestamp: "2021-10-06T18:20:13Z"
 labels:
   authz.cluster.cattle.io/impersonator: "true"
   cattle.io/creator: norman
 name: cattle-impersonation-user-abcde
 resourceVersion: "3528"
 uid: a7478731-72a0-4343-b09f-c3bf12552d77
rules:
# allowed to impersonate user user-abcde
- apiGroups:
 - ""
 resourceNames:
 - user-abcde
 resources:
 - users
 verbs:
 - impersonate
# allowed to impersonate listed groups
- apiGroups:
 - ""
 resourceNames:
 - github_team://123 # group from GitHub auth provider
 - system:authenticated # automatic group from Kubernetes
 - system:cattle:authenticated # automatic group from Rancher
 resources:
 - groups
 verbs:
 - impersonate
# allowed to impersonate principal ID github_user://098
- apiGroups:
 - authentication.k8s.io
 resourceNames:
 - github_user://098 # principal ID from GitHub auth provider
 resources:
 - userextras/principalid
 verbs:
 - impersonate
# allowed to impersonate username example
- apiGroups:
 - authentication.k8s.io
 resourceNames:
 - example # username from GitHub auth provider
 resources:
 - userextras/username
 verbs:
 - impersonate

Lorsque vous dépannez des problèmes d’imitation, vérifiez si ces ressources existent pour l’utilisateur et si les règles dans le rôle de cluster ressemblent à celles ci-dessus. Par exemple :

kubectl --namespace cattle-impersonation-system get serviceaccount cattle-impersonation-<user ID>
kubectl --namespace cattle-impersonation-system get secret cattle-impersonation-<user ID>-token-<hash>
kubectl get clusterrole cattle-impersonation-<user ID> --output yaml
kubectl get clusterrolebinding cattle-impersonation-<user ID>

Si vous voyez une erreur liée à "l’imitation" dans l’interface utilisateur, prêtez une attention particulière à end du message d’erreur, qui devrait indiquer la véritable raison pour laquelle la demande a échoué.

Fichiers importants

Les fichiers mentionnés ci-dessous sont nécessaires pour maintenir, dépanner et mettre à niveau votre cluster :

config.yaml : Le fichier de configuration du cluster RKE2 et K3s.
rke2.yaml ou k3s.yaml : Le fichier Kubeconfig pour votre cluster RKE2 ou K3s. Ce fichier contient des informations d’identification pour un accès complet au cluster. Vous pouvez utiliser ce fichier pour vous authentifier auprès d’un cluster Kubernetes lancé par Rancher si Rancher tombe en panne.

Pour plus d’informations sur la connexion à un cluster sans le proxy d’authentification Rancher et d’autres options de configuration, consultez la documentation du fichier kubeconfig.

Outils pour la fourniture de clusters Kubernetes

Les outils que Rancher utilise pour provisionner des clusters utilisateur en aval dépendent du type de cluster qui est provisionné.

Kubernetes lancé par Rancher pour des nœuds hébergés dans un fournisseur d’infrastructure

Rancher peut provisionner dynamiquement des nœuds dans un fournisseur tel qu’Amazon EC2, DigitalOcean, Azure ou vSphere, puis installer Kubernetes dessus.

Rancher provisionne ce type de cluster en utilisant docker-machine.

Kubernetes lancé par Rancher pour des nœuds personnalisés

Lors de la configuration de ce type de cluster, Rancher installe Kubernetes sur des nœuds existants, ce qui crée un cluster personnalisé.

Rancher provisionne ce type de cluster en utilisant RKE2 ou K3s.

Fournisseurs Kubernetes hébergés

Lors de la configuration de ce type de cluster, Kubernetes est installé par des fournisseurs tels que Google Kubernetes Engine, Amazon Elastic Container Service for Kubernetes ou Azure Kubernetes Service.

Rancher provisionne ce type de cluster en utilisant kontainer-engine.

Clusters Kubernetes importés

Dans ce type de cluster, Rancher se connecte à un cluster Kubernetes qui a déjà été configuré. Par conséquent, Rancher ne provisionne pas Kubernetes, mais configure uniquement les agents Rancher pour communiquer avec le cluster.

Composants du serveur Rancher et code source

Ce diagramme montre chaque composant dont le serveur Rancher est composé :

Les dépôts GitHub pour Rancher peuvent être trouvés aux liens suivants :

Ceci est une liste partielle des dépôts Rancher les plus importants. Pour plus de détails sur le code source de Rancher, référez-vous à la section sur contribuer à Rancher. Pour voir toutes les bibliothèques et projets utilisés dans Rancher, consultez le go.mod fichier dans le rancher/rancher dépôt.