Gérer des clusters depuis la console Google Cloud

Ce document explique comment rendre les clusters d'administrateur et d'utilisateur créés avec le logiciel Google Distributed Cloud sur Bare Metal disponibles pour la gestion dans la console Google Cloud. Les fonctionnalités de gestion des clusters incluent la possibilité de se connecter aux clusters, d'afficher les charges de travail, de mettre à niveau, de mettre à jour et de supprimer des clusters.

Membres du parc et console

Tous les clusters doivent être membres d'un parc, un moyen unifié d'afficher et de gérer plusieurs clusters et leurs charges de travail. Chaque parc de clusters est associé à un projet hôte de parc.

Tous les clusters sont enregistrés dans un parc au moment de leur création :

Lorsque vous créez un cluster à l'aide de bmctl, vous spécifiez votre projet hôte de parc dans la section gkeConnect du fichier de configuration du cluster. Le cluster devient membre d'une flotte du projet spécifié.
Lorsque vous créez un cluster d'administrateur ou d'utilisateur avec un client API GKE On-Prem standard (la console, Google Cloud CLI ou Terraform), le cluster devient membre d'une flotte dans le projet spécifié.

Les membres du parc en dehors de Google Cloud, tels que Google Distributed Cloud, s'affichent dans la console de votre projet hôte de parc, avec d'autres clusters de parc tels que GKE sur Google Cloud. La mesure dans laquelle vous pouvez gérer des clusters Bare Metal à partir de la console dépend des éléments suivants :

Si vous avez configuré l'authentification, vous pouvez vous connecter à vos clusters et afficher leurs charges de travail et d'autres détails.
Si la gestion du cycle de vie des clusters est activée pour le cluster, vous pouvez mettre à niveau les clusters d'administrateur et d'utilisateur à l'aide de la console, et vous pouvez utiliser la console pour mettre à jour et supprimer des clusters d'utilisateur. Si cette fonctionnalité n'est pas activée, vous ne pouvez gérer le cycle de vie du cluster qu'à l'aide de bmctl sur votre poste de travail administrateur.

Afficher les clusters enregistrés

Tous vos clusters s'affichent sur la page Clusters GKE de la console. Cela vous donne une vue d'ensemble de votre parc et, pour Google Distributed Cloud, vous permet de voir quels clusters sont gérés par l'API GKE On-Prem.

Pour afficher les clusters de votre parc, procédez comme suit :

Dans la console, accédez à la page Présentation des clusters Google Kubernetes Engine.

Accéder aux clusters GKE
Sélectionnez le projet Google Cloud.
- Si Bare Metal est affiché dans la colonne Type, le cluster est géré par l'API GKE On-Prem. Remarque : Seuls les clusters d'administrateur et d'utilisateur peuvent être gérés par l'API GKE On-Prem.
- Si Externe s'affiche dans la colonne Type, cela signifie que le cluster n'est pas géré par l'API GKE On-Prem.

Pour obtenir plus d'informations sur un cluster, vous devez vous connecter et vous authentifier auprès du cluster. Pour ce faire, procédez comme suit :

Configurer une méthode d'authentification
Attribuer des rôles Identity and Access Management spécifiques aux utilisateurs

Configurer l'authentification

Comme décrit précédemment, tous les clusters s'affichent sur la page des clusters GKE dans la console. Toutefois, pour afficher plus de détails, tels que les nœuds et les charges de travail (et pour effectuer des tâches de gestion du cycle de vie du cluster si la fonctionnalité est activée), vous devez vous connecter et vous authentifier auprès du cluster. Pour ce faire, vos clusters doivent être configurés avec l'une des méthodes d'authentification suivantes :

Identité Google : cette option vous permet de vous connecter à l'aide de votre identité Google Cloud, qui correspond à l'adresse e-mail associée à votre compte Google Cloud. Utilisez cette option si les utilisateurs ont déjà accès à Google Cloud avec leur identité Google. Si vous avez créé le cluster dans la console, vous pouvez vous y connecter en utilisant votre identité Google, mais vous devrez configurer l'authentification pour les autres utilisateurs.

La connexion avec l'identité Google est l'approche la plus simple pour l'authentification dans la console. Nous avons donc décrit comment configurer cela plus en détail dans la section Configurer l'authentification avec l'identité Google.
OpenID Connect (OIDC) : cette option vous permet de vous connecter aux clusters depuis la console en utilisant leur identité d'un fournisseur d'identité OIDC tiers tel que Okta ou Microsoft AD FS. Vous pouvez utiliser cette option si vos utilisateurs disposent de noms d'utilisateur, de mots de passe et d'appartenances à des groupes de sécurité existants de votre fournisseur. Pour savoir comment configurer l'authentification OIDC tierce pour vos clusters, consultez les guides suivants :
- Configurer des clusters pour GKE Identity Service avec OIDC : ce guide vous explique comment configurer l'authentification OIDC par cluster.
- Configurer GKE Identity Service pour un parc : cette option vous permet de configurer OIDC au niveau du parc.
Jeton de support : si les solutions précédentes fournies par Google ne sont pas adaptées à votre organisation, vous pouvez configurer l'authentification à l'aide d'un compte de service Kubernetes et de son jeton de support pour vous connecter. Pour en savoir plus, consultez la page Configurer à l'aide d'un jeton de support.

Attribuer les rôles requis

L'accès à la console est contrôlé par Identity and Access Management (IAM). Pour gérer le cycle de vie du cluster dans la console, vous devez attribuer certains rôles IAM aux utilisateurs qui ne sont pas propriétaires de projet :

Pour permettre aux utilisateurs d'accéder à la console, vous devez au minimum attribuer les rôles suivants :
- roles/container.viewer : ce rôle permet aux utilisateurs d'afficher la page "Clusters GKE" et les autres ressources de conteneur dans la console. Pour en savoir plus sur les autorisations incluses dans ce rôle ou pour accorder à un rôle des autorisations de lecture et d'écriture, consultez la section Rôles Kubernetes Engine dans la documentation IAM.
- roles/gkehub.viewer : ce rôle permet aux utilisateurs d'afficher les clusters en dehors de Google Cloud dans la console. Pour en savoir plus sur les autorisations incluses dans ce rôle ou pour attribuer un rôle doté d'autorisations de lecture et d'écriture, consultez la page Rôles GKE Hub dans la documentation IAM.
Pour permettre aux utilisateurs de gérer le cycle de vie du cluster dans la console, accordez le rôle IAM roles/gkeonprem.admin. Le rôle roles/gkeonprem.admin accorde aux utilisateurs un accès administrateur à l'API GKE On-Prem que la console utilise pour gérer le cycle de vie du cluster. Pour en savoir plus sur les autorisations incluses dans ce rôle, consultez la section Rôles GKE On-Prem dans la documentation IAM.

Les commandes suivantes montrent comment attribuer les rôles minimaux nécessaires pour gérer le cycle de vie du cluster dans la console :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkeonprem.admin

où :

PROJECT_ID correspond au projet hôte du parc. Pour les clusters créés à l'aide de bmctl, il s'agit du projet que vous avez configuré dans la section gkeConnect du fichier de configuration du cluster d'utilisateur. Pour les clusters créés dans la console, il s'agit du projet que vous avez choisi lors de la création du cluster.
MEMBER est l'adresse e-mail de l'utilisateur au format user:emailID, par exemple : user:alice@example.com

Activer la gestion du cycle de vie des clusters dans la console

Les clusters d'administrateur et d'utilisateur créés à l'aide d'outils standards (la console, gcloud CLI ou Terraform) sont automatiquement enregistrés dans l'API GKE On-Prem, ce qui vous permet d'effectuer des tâches de gestion du cycle de vie des clusters dans la console. Dans Google Distributed Cloud 1.16 et versions ultérieures, lorsque vous créez des clusters d'utilisateur et d'administrateur à l'aide de bmctl, ils sont enregistrés par défaut dans l'API GKE On-Prem. Si vous devez enregistrer un cluster dans l'API GKE On-Prem, suivez la procédure décrite dans la section Configurer un cluster pour qu'il soit géré par l'API GKE On-Prem.

Configurer l'authentification avec l'identité Google

Pour permettre aux utilisateurs de se connecter au cluster à l'aide de leur identité Google, vous devez configurer les éléments suivants :

Les utilisateurs ont besoin de rôles Identity and Access Management (IAM) spécifiques pour pouvoir afficher et interagir avec les clusters dans la console sur la page Clusters GKE.
Les utilisateurs doivent être ajoutés aux stratégies de contrôle des accès basé sur les rôles (RBAC) Kubernetes dont la passerelle Connect a besoin pour accéder au serveur d'API Kubernetes du cluster à l'aide de l'agent Connect.

Configurer l'autorisation RBAC

Le serveur d'API Kubernetes de chaque cluster doit être en mesure d'autoriser les requêtes provenant de la console. Pour configurer l'autorisation, vous devez configurer des stratégies de contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de chaque cluster. Votre compte Google est ajouté en tant qu'administrateur disposant d'un accès complet à un cluster d'utilisateurs dans les cas suivants :

Vous avez créé le cluster d'utilisateur dans la console.
Vous avez créé le cluster d'utilisateur à l'aide de gCloud CLI et votre compte Google a été spécifié dans l'option --admin-users de la commande de création de cluster.
Vous avez créé le cluster d'utilisateurs à l'aide de Terraform et votre compte Google a été spécifié dans le champ authorization.admin_users.username.
Vous avez créé le cluster d'utilisateurs à l'aide de bmctl et configuré votre compte Google dans clusterSecurity.authorization.clusterAdmin.gcpAccounts.

Vous pouvez ajouter d'autres administrateurs après la création du cluster. Vous pouvez utiliser l'une des méthodes suivantes pour accorder un accès administrateur au cluster. Deux commandes gcloud différentes sont fournies.

La commande gcloud ... generate-gateway-rbac doit être exécutée sur votre poste de travail administrateur, car elle nécessite un accès au kubeconfig et au contexte du cluster (qui ne se trouvent généralement que sur votre poste de travail administrateur). La commande generate-gateway-rbac vous permet de personnaliser les stratégies RBAC, mais les adresses e-mail des utilisateurs ne seront pas affichées en tant qu'administrateurs dans la section Détails du cluster de la console.
La commande gcloud ... update peut être exécutée sur votre poste de travail administrateur ou sur n'importe quel ordinateur ayant accès à l'API GKE On-Prem.

Notez que si vous avez créé un cluster d'administrateur dans la console Google Cloud, vous disposez d'un accès en lecture seule à ce cluster. Si vous souhaitez obtenir le rôle clusterrole/cluster-admin, une personne disposant de ce rôle doit vous ajouter à l'aide de la commande gcloud ... generate-gateway-rbac.

`generate-gateway-rbac`

Pour appliquer les règles RBAC aux utilisateurs, procédez comme suit sur votre poste de travail administrateur :

Exécutez la commande suivante pour mettre à jour les composants (si nécessaire) :
```
gcloud components update
```
Générez et appliquez les stratégies RBAC à votre cluster pour les utilisateurs et les comptes de service :
```
gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply
```
Remplacez les éléments suivants :
- MEMBERSHIP_NAME : nom utilisé pour représenter de manière unique le cluster dans son parc. Dans Google Distributed Cloud, le nom de l'appartenance et le nom du cluster sont identiques.
- ROLE : rôle Kubernetes que vous souhaitez attribuer aux utilisateurs du cluster. Pour accorder aux utilisateurs un accès complet à toutes les ressources du cluster dans tous les espaces de noms, spécifiez clusterrole/cluster-admin. Pour fournir un accès en lecture seule, spécifiez clusterrole/view. Pour restreindre l'accès, créez un rôle personnalisé, par exemple : role/mynamespace/namespace-reader. Le rôle personnalisé doit déjà exister avant l'exécution de la commande.
- USERS : adresses e-mail des utilisateurs (comptes utilisateur ou comptes de service) auxquels vous souhaitez accorder les autorisations, sous la forme d'une liste d'éléments séparés par une virgule. Exemple : --users=222larabrown@gmail.com,test-acct@test-project.iam.gserviceaccount.com.
- PROJECT_ID : ID du projet hôte du parc.
- KUBECONFIG_PATH : chemin d'accès local de votre fichier kubeconfig contenant une entrée pour le cluster.
- KUBECONFIG_CONTEXT : contexte du cluster tel qu'il apparaît dans le fichier kubeconfig. Vous pouvez obtenir le contexte actuel à partir de la ligne de commande en exécutant la commande kubectl config current-context. Que vous utilisiez le contexte actuel ou non, assurez-vous qu'il fonctionne pour l'accès au cluster en exécutant une commande simple telle que la suivante :
```
kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT
```
Une fois la commande gcloud container fleet memberships generate-gateway-rbac exécutée, un message semblable à ce qui suit s'affiche à la fin du résultat, qui est tronqué par souci de lisibilité :
```
Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind
Writing RBAC policy for user: foo@example.com to cluster.
Successfully applied the RBAC policy to cluster.
```
Il s'agit du contexte permettant d'accéder au cluster via la passerelle Connect.

Pour en savoir plus sur la commande generate-gateway-rbac, consultez le guide de référence de gcloud CLI.

`update`

Exécutez la commande suivante pour mettre à jour les composants :
```
gcloud components update
```
Pour chaque utilisateur auquel vous devez attribuer le rôle clusterrole/cluster-admin, ajoutez l'option --admin-users et exécutez la commande suivante. Vous ne pouvez pas spécifier plusieurs utilisateurs dans un même indicateur. Veillez à inclure votre compte Google dans la commande, car celle-ci remplace la liste d'autorisation par les utilisateurs que vous spécifiez dans la commande.
```
gcloud container bare-metal clusters update USER_CLUSTER_NAME \
  --admin-users YOUR_GOOGLE_ACCOUNT \
  --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
```

En plus d'accorder le rôle clusterrole/cluster-admin Kubernetes, la commande accorde les stratégies RBAC dont les utilisateurs ont besoin pour accéder au cluster via la passerelle Connect.

bmctl