Vous pouvez vous authentifier avec les clusters Anthos clusters on bare metal à l'aide d'OpenID Connect (OIDC). OIDC est une couche d'authentification basée sur OAuth 2.0 qui spécifie une API HTTP RESTful, et utilise JSON comme format de données.
OIDC vous permet d'utiliser votre fournisseur d'identité existant pour gérer l'authentification des utilisateurs et des groupes dans les clusters Anthos clusters on bare metal. Avec OIDC, vous pouvez gérer l'accès à un cluster Anthos clusters on bare metal, en appliquant les procédures standards de votre organisation pour créer, activer et désactiver des comptes. Vous pouvez également utiliser les groupes de sécurité de votre organisation pour configurer l'accès à un cluster ou à des services spécifiques d'un cluster. L'accès géré fonctionne sur n'importe quel type de cluster Anthos clusters on bare metal : administrateur, utilisateur, hybride ou autonome.
Anthos clusters on bare metal est compatible avec les fournisseurs d'identité accessibles publiquement et ceux hébergés sur site. Par exemple, sur site, vous pouvez utiliser un composant de services de fédération Active Directory. Vous pouvez également utiliser des services de gestion des identités accessibles publiquement fournis par Google ou Okta. En outre, les certificats du fournisseur d'identité peuvent être émis par une autorité de certification publique bien connue ou par une autorité de certification privée.
Deux méthodes d'authentification OIDC sont disponibles pour les utilisateurs :
L'authentification OIDC via une interface de ligne de commande (CLI) dans laquelle les utilisateurs exécutent une commande gcloud et sont authentifiés via une page de connexion ou d'autorisation basée sur le navigateur.
L'authentification OIDC via l'interface utilisateur de la console Google Cloud, où les utilisateurs se connectent à un cluster directement à partir de la page des clusters Kubernetes. Cette méthode nécessite que votre cluster soit enregistré auprès de Google Cloud. Les clusters sont enregistrés automatiquement lors de l'installation d'un cluster Anthos clusters on bare metal.
Notez qu'OIDC n'est pas compatible avec les workflows sans interface graphique : OIDC nécessite une authentification basée sur un navigateur pour rediriger les utilisateurs vers la page Web du fournisseur d'identité, et pour leur demander de donner leur consentement et de se connecter avec leur identifiant/mot de passe.
OIDC et contrôle des accès Kubernetes
L'authentification OIDC est souvent combinée au contrôle des accès basé sur les rôles Kubernetes (RBAC). Le contrôle RBAC vous permet de créer des stratégies d'autorisation précises qui définissent les utilisateurs ou les groupes pouvant effectuer des opérations spécifiques sur un ensemble donné de ressources de cluster.
Présentation de l'authentification OIDC
Une authentification OIDC classique comprend les étapes suivantes :
- Un utilisateur se connecte à un fournisseur OpenID en présentant un nom d'utilisateur et un mot de passe.
Le fournisseur OpenID émet un jeton d'ID pour l'utilisateur.
Le jeton est signé par le fournisseur et est renvoyé via une URL de rappel préconfigurée.
Une application, agissant pour le compte de l'utilisateur, envoie une requête HTTPS au serveur d'API Kubernetes. L'application inclut le jeton d'ID de l'utilisateur dans l'en-tête de la requête.
Le serveur d'API Kubernetes vérifie le jeton d'ID à l'aide du certificat du fournisseur, puis analyse le jeton pour connaître l'identité de l'utilisateur et, le cas échéant, ses groupes.
La configuration et l'authentification d'OIDC font généralement intervenir trois types de personnes :
L'administrateur de l'organisation, qui choisit un fournisseur OpenID et enregistre les applications clientes auprès du fournisseur.
Un administrateur de plate-forme qui crée un ou plusieurs clusters et des fichiers de configuration d'authentification pour les utilisateurs qui utilisent les clusters.
Un opérateur ou un développeur d'applications, qui exécute des charges de travail sur un ou plusieurs clusters et s'authentifie à l'aide d'OIDC.
Vous pouvez utiliser n'importe quel fournisseur OpenID certifié (les fournisseurs sont certifiés par l'OpenID Foundation). Le processus d'enregistrement spécifique dépend du fournisseur, mais comprend généralement les étapes suivantes :
Découvrir l'URI d'émetteur du fournisseur. C'est à ce moment que gcloud CLI ou Google Cloud Console envoient des requêtes d'authentification.
Indiquez au fournisseur les URL de redirection de gcloud CLI et de la console Google Cloud.
Établir un ID client et un code secret du client. La console Google Cloud et gcloud CLI utilisent tous deux cet ID client/ce secret pour s'authentifier auprès du fournisseur OpenID.
Établissez un champ d'application personnalisé et revendiquez les groupes de sécurité. En général, les stratégies RBAC de cluster que vous définissez doivent être basées des groupes plutôt que sur des utilisateurs. Cela permet de les rendre plus stables et contrôlables. La plupart des fournisseurs OIDC incluent des revendications de groupe dans des jetons d'ID si des champs d'application appropriés ont été demandés. Les revendications et champs d'application de groupe spécifiques diffèrent selon les fournisseurs OIDC. Par conséquent, l'établissement de ces champs d'application et de revendications propres à chaque fournisseur nécessitent une personnalisation.
Avant d'installer un nouveau cluster Anthos clusters on bare metal, l'administrateur de la plate-forme obtient normalement la configuration OIDC auprès de l'administrateur de l'organisation et configure les champs OIDC appropriés dans la configuration du cluster.
Une fois l'installation du cluster terminée, l'administrateur de la plate-forme obtient les fichiers de configuration d'authentification et les partage avec les utilisateurs de la CLI. En règle générale, l'administrateur de la plate-forme partage la configuration d'authentification en hébergeant les fichiers sur un hôte sécurisé ou en utilisant des outils internes pour transférer les fichiers de configuration sur l'ordinateur de chaque utilisateur. Les utilisateurs de la CLI authentifient ensuite le nouveau cluster avec les fichiers de configuration partagés.
L'administrateur de la plate-forme peut également stocker lesdétails de configuration d'authentification pour plusieurs clusters dans un seul fichier de configuration d'authentification.
Notez que les utilisateurs de la console Google Cloud n'ont pas besoin de ces fichiers de configuration.
Lorsque les utilisateurs accèdent à la console Google Cloud, ils peuvent sélectionner Authenticate
with the Identity Provider configuré pour le cluster, puis cliquer sur Login..