Google Cloud

$ dormeto gcp check --project my-project --region europe-west1project my-project: billing enabled✓ check  ✓ install  ✓ install-router  ✓ uninstall✓ workloads  ✓ onboard  ✓ offboard

Ce dont il a besoin

Les API

dormeto gcp install active ces dix API, de la forme .googleapis.com, dans le projet. uninstall n'en désactive aucune : d'autres éléments du projet peuvent les utiliser.

Les rôles

Deux rôles personnalisés, créés dans le projet, et quatre rôles prédéfinis. Chaque permission ci-dessous figure dans le manifeste que le routeur et la CLI partagent. Les tests du routeur vérifient que chaque appel qu'il fait à Google Cloud est couvert par l'une d'elles.

dormetoRouter

Dormeto router. Permet à un routeur Dormeto de lire les équilibreurs de charge, les VM et les groupes de ses workloads, et de modifier leurs URL maps. Il peut créer et supprimer leurs services de backend du waker, et désactiver et réactiver leurs autoscalers. Il lit aussi leur nombre de requêtes.

Google classe compute.urlMaps.get, compute.urlMaps.list et compute.urlMaps.update en testing dans les rôles personnalisés : utilisables, mais non recommandées en production par Google. Aucun rôle prédéfini plus étroit ne les contient, donc dormetoRouter les garde. Un autoscaler ne peut pas porter de tag : compute.autoscalers.update figure donc ici, sans la condition du tag.

dormetoRouterBackends

Dormeto router backends. Permet à un routeur Dormeto de démarrer, arrêter, suspendre et reprendre les VM et les groupes d'instances gérés de ses workloads. Accordé à la condition que la ressource porte le tag dormeto=managed.

Accordé à la condition que la ressource porte le tag dormeto=managed. La modification d'un autoscaler désigne son groupe : compute.instanceGroupManagers.update et .use sont donc vérifiées sur le tag du groupe.

Rôles prédéfinis

Accordés comme décrit dans les droits. Dormeto s'appuie sur ces permissions de chacun :

Les droits accordés

Le routeur s'exécute avec le compte de service dmtr-<region>@<project>.iam.gserviceaccount.com. La CLI ajoute exactement ces liaisons, et seulement celles-ci. Elle ne modifie ni ne supprime jamais une liaison qu'elle n'a pas ajoutée. Dans une condition, {project} est l'ID du projet et {database} la base du routeur, dmtr-<region>.

Ce que Google ajoute

Activer des API et créer des ressources conduit Google à ajouter ses propres liaisons à la politique IAM du projet. Dormeto n'en utilise aucune pour son travail. La CLI affiche chacune comme venant de Google, avec l'étape après laquelle elle est apparue, puis l'enregistre. Sur un vrai projet, sept ont été ajoutées pendant l'installation, et une huitième à la création du dépôt de l'image :

Les noms d'étapes sont ceux du tableau de l'opérateur. Les agents de service sont gérés par Google : laissez-les. uninstall les laisse aussi, et les liste comme laissés en place. Les agents de service propres à Compute Engine, déjà présents dès que Compute Engine est activé, sont eux aussi à Google.

Le rôle Éditeur du compte de service par défaut

Prenons un projet hors d'une organisation qui impose la contrainte iam.automaticIamGrantsForDefaultServiceAccounts. Quand Compute Engine est activé, Google donne à son compte de service par défaut, <project number>-compute@developer.gserviceaccount.com, le rôle roles/editor sur tout le projet. Dormeto ne l'utilise pas : les services Cloud Run du routeur s'exécutent avec dmtr-<region>. dormeto gcp check signale cette liaison par un avertissement et la laisse : c'est à vous de la retirer. Avant cela, vérifiez quelles VM, quels modèles d'instance et quels services s'exécutent avec ce compte, car ils perdent ce que l'Éditeur leur donnait :

gcloud compute instances list --format="table(name,zone.basename(),serviceAccounts[].email)"
gcloud projects remove-iam-policy-binding my-project \
  --member="serviceAccount:123456789012-compute@developer.gserviceaccount.com" \
  --role="roles/editor"

Pour que Google ne l'accorde plus dans vos prochains projets, imposez iam.automaticIamGrantsForDefaultServiceAccounts sur l'organisation ou le dossier.

Les permissions de l'opérateur

Vous lancez la CLI avec votre compte gcloud (sa configuration active, ou --gcloud-configuration). Chaque commande teste les permissions de ses étapes avant de rien modifier : une seule manquante l'arrête sans rien changer. roles/owner les contient toutes. Les tableaux listent les étapes de chaque commande, comme le fait le manifeste.

dormeto gcp check

dormeto gcp install

dormeto gcp install --image

S'ajoute à install quand vous indiquez l'image du routeur.

dormeto gcp uninstall

dormeto gcp workloads list

Aussi show, nap et wake : ils appellent le contrôleur du routeur avec votre jeton d'identité.

dormeto gcp workloads onboard

dormeto gcp workloads offboard

Un rôle personnalisé pour un opérateur plus restreint

Si roles/owner est trop large, créez un rôle avec les permissions des commandes que cet opérateur lance. Celui-ci contient toutes les permissions des tableaux ci-dessus :

title: Dormeto operator
description: Runs dormeto gcp in this project
stage: GA
includedPermissions:
- artifactregistry.dockerimages.get
- artifactregistry.repositories.downloadArtifacts
- artifactregistry.repositories.get
- cloudscheduler.jobs.create
- cloudscheduler.jobs.delete
- cloudscheduler.jobs.get
- cloudscheduler.jobs.update
- cloudtasks.queues.create
- cloudtasks.queues.delete
- cloudtasks.queues.get
- cloudtasks.queues.getIamPolicy
- cloudtasks.queues.setIamPolicy
- cloudtasks.queues.update
- compute.instanceGroupManagers.createTagBinding
- compute.instanceGroupManagers.deleteTagBinding
- compute.instanceGroupManagers.listTagBindings
- compute.instances.createTagBinding
- compute.instances.deleteTagBinding
- compute.instances.listTagBindings
- compute.regionNetworkEndpointGroups.create
- compute.regionNetworkEndpointGroups.delete
- compute.regionNetworkEndpointGroups.get
- compute.regionOperations.get
- datastore.databases.create
- datastore.databases.delete
- datastore.databases.get
- datastore.databases.list
- datastore.entities.create
- datastore.entities.get
- datastore.entities.list
- datastore.entities.update
- datastore.operations.get
- iam.roles.create
- iam.roles.delete
- iam.roles.get
- iam.roles.undelete
- iam.roles.update
- iam.serviceAccounts.actAs
- iam.serviceAccounts.create
- iam.serviceAccounts.delete
- iam.serviceAccounts.get
- iam.serviceAccounts.getIamPolicy
- iam.serviceAccounts.setIamPolicy
- resourcemanager.projects.get
- resourcemanager.projects.getIamPolicy
- resourcemanager.projects.setIamPolicy
- resourcemanager.tagKeys.create
- resourcemanager.tagKeys.delete
- resourcemanager.tagKeys.get
- resourcemanager.tagValueBindings.create
- resourcemanager.tagValueBindings.delete
- resourcemanager.tagValues.create
- resourcemanager.tagValues.delete
- resourcemanager.tagValues.get
- run.operations.get
- run.routes.invoke
- run.services.create
- run.services.delete
- run.services.get
- run.services.getIamPolicy
- run.services.setIamPolicy
- run.services.update
- serviceusage.operations.get
- serviceusage.services.enable
- serviceusage.services.list
- serviceusage.services.use

gcloud iam roles create dormetoOperator --project=my-project --file=operator-role.yaml
gcloud projects add-iam-policy-binding my-project \
  --member="user:you@example.com" --role="projects/my-project/roles/dormetoOperator"

Retirez les permissions des commandes que vous ne donnez pas, puis vérifiez le résultat avec dormeto gcp check, qui liste ce qui manque pour chaque commande. Notez que resourcemanager.projects.setIamPolicy permet à son titulaire de s'accorder n'importe quel rôle dans le projet. Donnez ce rôle le temps de l'installation puis retirez-le. Ou réservez-le aux quelques personnes qui la lancent.

Google classe trois de ces permissions en TESTING dans les rôles personnalisés, comme compute.urlMaps.* : cloudtasks.queues.getIamPolicy, cloudtasks.queues.setIamPolicy et serviceusage.operations.get. Elles sont utilisables et aucune n'est refusée.

Accès facultatifs

À partir du routeur 0.35.0 et de la CLI 0.8.0. Activer l'API Cloud SQL ou GKE fait ajouter à Google ses propres agents de service. Un projet qui n'utilise aucun des deux ne doit pas les recevoir. Vous demandez donc chacun par son nom :

dormeto gcp install --with cloud-sql,gke

L'enregistrement de l'installation garde votre choix. Une exécution ultérieure avec davantage de fonctions les ajoute. Une exécution sans --with garde ce qui existe. Seul uninstall retire une fonction. dormeto gcp check ne teste une fonction que si --with la nomme ou si l'enregistrement la contient. L'exécution suivante de la CLI affiche toute association ajoutée par Google.

cloud-sql

Jamais exécuté contre Google pour l'instant. Une base de données associée, arrêtée par une mise en veille et démarrée par un réveil. API : sqladmin.googleapis.com.

gke

Jamais exécuté contre Google pour l'instant. Des pods derrière des groupes de points de terminaison réseau autonomes, sur un équilibreur de charge à vous. API : container.googleapis.com.

Le rôle n'accorde rien dans le cluster. Quand vous intégrez un workload, la CLI lit le cluster en votre nom. Elle affiche, demande et applique ensuite un Role et un RoleBinding nommés dormeto-<workload>, dans le namespace du workload, pour le compte de service du routeur. Rien ne s'applique à tout le cluster, et la sortie retire les deux. Les règles :

• get sur deployments, statefulsets.
• list sur replicasets.
• patch sur deployments/scale, statefulsets/scale.
• list sur pods, events.
• list, patch sur scaledobjects.

Kubernetes ne laisse accorder que ce que l'on détient : l'opérateur a donc besoin de container.roles.escalate et de container.roles.bind. Google classe container.roles.escalate en TESTING dans les rôles personnalisés.

Listes d'adresses IP

À partir du routeur 0.35.0. Avec --ip-list name=<n>,url=<u>[,refresh=<hours>], répétable, une visite depuis une adresse de la liste ne réveille jamais un workload. Un POST /_dormeto/wake d'un client d'API le réveille toujours. --no-ip-lists les efface. Elles ne demandent aucun rôle de plus. L'URL d'une liste, chaîne de requête comprise, est affichée et enregistrée dans le plan, l'enregistrement de l'installation et l'environnement des services. N'y mettez pas de jeton. Une URL avec des identifiants est refusée.

Si Terraform écrit votre équilibreur de charge et vos VM

Terraform ignore ce que le routeur écrit : chaque plan propose donc de l'annuler. Après un tel apply, la vérification du routeur répare la carte d'URL en moins de 5 minutes. D'ici là, un workload en veille affiche la page d'erreur de l'équilibreur de charge et ne se réveille pas depuis un navigateur. Ignorez ces champs sur les ressources que vous avez écrites, avec lifecycle { ignore_changes = [...] } :

Avec les path matchers ignorés, Terraform n'applique plus vos propres modifications. Retirez l'ignore le temps de cet apply. Cela retire aussi ce que le routeur a écrit jusqu'à ce que sa vérification le réécrive. L'association du tag n'est pas un champ de ces ressources : elle n'a besoin de rien.

Vérifier

dormeto gcp check est en lecture seule. Pour chaque commande, il affiche une coche quand vous détenez toutes les permissions nécessaires, et une croix avec les manquantes sinon. Il affiche ensuite le parent du projet, les API déjà activées et les avertissements (le rôle Éditeur du compte de service par défaut). Il se termine par le code 1 quand une commande manque d'une permission. Sans aucun rôle dans le projet, il le dit et liste toutes les permissions comme manquantes. --json affiche le rapport.

dormeto gcp check --project my-project --region europe-west1

dormeto gcp status affiche l'enregistrement du routeur et son état réel : version, services, santé du contrôleur, file, job, base et droits.

Retirer

dormeto gcp uninstall retire exactement ce que l'installation a ajouté, dans l'ordre inverse, d'après son enregistrement. Il refuse tant que des workloads sont intégrés. --force les sort d'abord un par un, associations du tag comprises. Il garde les rôles personnalisés et le tag tant qu'un autre routeur du projet les liste. Il ne désactive aucune API. Il liste les API et les liaisons de Google comme laissées en place.

dormeto gcp uninstall --project my-project --region europe-west1
dormeto gcp uninstall --project my-project --region europe-west1 --force   # workloads still onboarded

Ensuite, si rien d'autre dans le projet n'en a besoin, désactivez vous-même les API. Retirez aussi le rôle Éditeur du compte de service par défaut comme ci-dessus :

gcloud services disable \
  compute.googleapis.com \
  run.googleapis.com \
  firestore.googleapis.com \
  cloudtasks.googleapis.com \
  cloudscheduler.googleapis.com \
  monitoring.googleapis.com \
  artifactregistry.googleapis.com \
  iam.googleapis.com \
  cloudresourcemanager.googleapis.com \
  logging.googleapis.com \
  --project my-project

Google peut refuser de désactiver une API tant qu'un autre service en dépend, ou demander --force. Décidez pour chacune : ces API peuvent servir à d'autres usages dans le projet.

Le nom d'une file supprimée reste bloqué jusqu'à 3 jours et l'ID d'une base supprimée environ 5 minutes. Réinstaller avant échoue, et la CLI le dit.