11.2. Comptes de service par défaut

Votre cluster OpenShift Container Platform contient des comptes de service par défaut pour la gestion du cluster et génère d'autres comptes de service pour chaque projet.

11.2.1. Comptes de service de cluster par défaut

Plusieurs contrôleurs d'infrastructure fonctionnent en utilisant les informations d'identification des comptes de service. Les comptes de service suivants sont créés dans le projet d'infrastructure OpenShift Container Platform (openshift-infra) au démarrage du serveur et se voient attribuer les rôles suivants à l'échelle du cluster :

Compte de serviceDescription

replication-controller

Le rôle de system:replication-controller lui a été attribué

deployment-controller

Le rôle de system:deployment-controller lui a été attribué

build-controller

Le rôle system:build-controller lui a été attribué. En outre, le compte de service build-controller est inclus dans la contrainte de contexte de sécurité privilégié pour créer des pods de construction privilégiés.

11.2.2. Comptes et rôles de service de projet par défaut

Trois comptes de service sont automatiquement créés dans chaque projet :

Compte de serviceUtilisation

builder

Utilisé par les pods de construction. Le rôle system:image-builder lui est attribué, ce qui permet de pousser des images vers n'importe quel flux d'images du projet en utilisant le registre interne de Docker.

deployer

Utilisé par les pods de déploiement et doté du rôle system:deployer, qui permet de visualiser et de modifier les contrôleurs de réplication et les pods dans le projet.

default

Utilisé pour exécuter tous les autres pods à moins qu'ils ne spécifient un compte de service différent.

Tous les comptes de service d'un projet se voient attribuer le rôle system:image-puller, qui permet d'extraire des images de n'importe quel flux d'images du projet à l'aide du registre interne d'images de conteneurs.

11.2.3. À propos des secrets de jetons de compte de service générés automatiquement

Dans la version 4.12, OpenShift Container Platform adopte une amélioration de Kubernetes en amont, qui active la fonctionnalité LegacyServiceAccountTokenNoAutoGeneration par défaut. Par conséquent, lors de la création de nouveaux comptes de service (SA), un secret de jeton de compte de service n'est plus automatiquement généré. Auparavant, OpenShift Container Platform ajoutait automatiquement un jeton de compte de service à un secret pour chaque nouveau SA.

Cependant, certaines fonctionnalités et charges de travail ont besoin de secrets de jetons de compte de service pour communiquer avec le serveur API Kubernetes, par exemple, OpenShift Controller Manager. Cette exigence sera modifiée dans une prochaine version, mais elle demeure dans OpenShift Container Platform 4.12. Par conséquent, si vous avez besoin d'un secret de jeton de compte de service, vous devez utiliser manuellement l'API TokenRequest pour demander des jetons de compte de service liés ou créer un secret de jeton de compte de service.

Après la mise à jour vers la version 4.12, les secrets de jetons de compte de service existants ne sont pas supprimés et continuent de fonctionner comme prévu.

Note

Dans la version 4.12, les secrets des jetons des comptes de service sont toujours générés automatiquement. Au lieu de créer deux secrets par compte de service, OpenShift Container Platform n'en crée plus qu'un. Dans une prochaine version, ce nombre sera encore réduit à zéro. Notez que les secrets dockercfg sont toujours générés et qu'aucun secret n'est supprimé lors des mises à jour.

Ressources complémentaires