Contraintes gérées

Les contraintes gérées sont des règles d'administration prédéfinies, conçues sur une plate-forme moderne, qui offrent un contrôle centralisé et automatisé sur vos ressources Compute Engine. Ils incluent une assistance intégrée pour les outils de déploiement sécurisé tels que Policy Simulator et le mode test.

Les contraintes gérées sont identifiables par le préfixe compute.managed.* et remplacent directement les anciennes contraintes compute.*.

Avantages

  • Déploiement et surveillance sécurisés : implémentez des règles avec un ensemble complet d'outils, un contrôle des modifications plus rapide et un déploiement progressif à l'aide de fonctionnalités de simulation et de test à blanc.
  • Journalisation cohérente : assure l'uniformité des messages de journalisation et d'erreur, ce qui simplifie la surveillance centralisée et rationalise les audits.

Héritage des règles

Les règles d'administration que vous définissez sur une ressource sont héritées par les descendants de cette ressource dans la hiérarchie des ressources. Par exemple, si vous appliquez une règle au niveau d'un dossier, Cloud de Confiance by S3NS l'applique à tous les projets de ce dossier.

Tarifs

Le service de règles d'administration, y compris les règles d'administration d'administration prédéfinies (anciennes), gérées et personnalisées, est proposé sans frais.

Avant de commencer

  • Si ce n'est pas déjà fait, configurez l'authentification. L'authentification permet de valider votre identité pour accéder aux services et aux API Cloud de Confiance by S3NS . Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine en sélectionnant l'une des options suivantes :

    Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :

    Console

    Lorsque vous utilisez la console Cloud de Confiance pour accéder aux services Cloud de Confiance by S3NS et aux API, vous n'avez pas besoin de configurer l'authentification.

    gcloud

    1. Installez la Google Cloud CLI, puis connectez-vous à la gcloud CLI avec votre identité fédérée. Après vous être connecté, initialisez la Google Cloud CLI en exécutant la commande suivante : 

      gcloud init
  • Définissez une région et une zone par défaut.

    • REST

    Pour utiliser les exemples API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à la gcloud CLI.

      Installez la Google Cloud CLI, puis connectez-vous à la gcloud CLI avec votre identité fédérée.

    Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Cloud de Confiance .

  • Assurez-vous de connaître votre ID d'organisation.
  • Si ce n'est pas déjà fait, installez la gcloud CLI et initialisez-la en exécutant gcloud init.
  • Définissez un projet par défaut pour vos tests.

Rôles requis

Pour obtenir les autorisations nécessaires pour gérer les règles d'administration avec des contraintes gérées, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour gérer les règles d'administration avec des contraintes gérées. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour gérer les règles d'administration avec des contraintes gérées :

  • orgpolicy.constraints.list
  • orgpolicy.policies.create
  • orgpolicy.policies.delete
  • orgpolicy.policies.list
  • orgpolicy.policies.update
  • orgpolicy.policy.get
  • orgpolicy.policy.set
  • Pour tester les contraintes :
    • compute.instances.create sur le projet
    • Pour créer la VM à l'aide d'une image personnalisée : compute.images.useReadOnly sur l'image
    • Pour créer la VM à l'aide d'un instantané : compute.snapshots.useReadOnly sur l'instantané
    • Pour créer la VM à l'aide d'un modèle d'instance : compute.instanceTemplates.useReadOnly sur le modèle d'instance
    • Pour attribuer un ancien réseau à la VM : compute.networks.use sur le projet
    • Pour spécifier une adresse IP statique pour la VM : compute.addresses.use sur le projet
    • Pour attribuer une adresse IP externe à la VM, en cas d'utilisation d'un ancien réseau : compute.networks.useExternalIp sur le projet
    • Pour spécifier un sous-réseau pour la VM : compute.subnetworks.use sur le projet ou sur le sous-réseau choisi
    • Pour attribuer une adresse IP externe à la VM, en cas d'utilisation d'un réseau VPC : compute.subnetworks.useExternalIp sur le projet ou sur le sous-réseau choisi
    • Pour définir les métadonnées d'instance de VM pour la VM : compute.instances.setMetadata sur le projet
    • Pour définir des tags pour la VM : compute.instances.setTags sur la VM
    • Pour définir des étiquettes pour la VM : compute.instances.setLabels sur la VM
    • Pour définir un compte de service que doit utiliser la VM : compute.instances.setServiceAccount sur la VM
    • Pour créer un disque pour la VM : compute.disks.create sur le projet
    • Pour associer un disque existant en mode lecture seule ou en mode lecture/écriture : compute.disks.use sur le disque
    • Pour associer un disque existant en mode lecture seule : compute.disks.useReadOnly sur le disque

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Contraintes gérées disponibles

Les contraintes de règles d'administration gérées suivantes sont disponibles pour Compute Engine :

Évaluation hiérarchique des métadonnées

Les contraintes gérées qui reposent sur des clés de métadonnées prédéfinies, telles que OS Login ou l'accès au port série, sont compatibles avec l'évaluation hiérarchique. Lorsque Compute Engine évalue ces contraintes, il vérifie les valeurs de métadonnées définies au niveau de l'instance de VM, du projet ou de la zone.

Définir des valeurs de métadonnées au niveau du projet ou de la zone vous permet de gérer les instances de VM à grande échelle. Toutefois, l'application des contraintes n'a lieu que lors des appels d'API de création ou de mise à jour d'instances de VM. Par conséquent, les modifications apportées aux métadonnées de projet ou de zone n'affectent la conformité des contraintes d'une instance de VM que lorsque cette instance est créée ou mise à jour.

Contraintes et niveaux basés sur les métadonnées

Contrainte Clé de métadonnée Niveaux de hiérarchie des métadonnées
compute.managed.disableSerialPortAccess serial-port-enable Projet, zonal, instance
compute.managed.requireOsLogin enable-oslogin Projet, zonal, instance
compute.managed.disableGuestAttributesAccess enable-guest-attributes Projet, zonal, instance
compute.managed.requireOsConfig enable-osconfig Projet, zonal, instance
compute.managed.disallowGlobalDns VmDnsSetting Projet, instance

Déploiement sécurisé : cycle de vie des règles

Pour éviter toute interruption de service lorsque vous implémentez progressivement de nouvelles contraintes, Google vous recommande d'implémenter des contraintes gérées en procédant comme suit :

Analyser avec Policy Simulator

Avant d'appliquer une règle, utilisez Policy Simulator pour identifier les ressources existantes qui ne la respectent pas. Procédez comme suit :

  1. Dans la console Cloud de Confiance , accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  2. Dans la barre de filtre, recherchez votre contrainte, puis cliquez sur son nom pour accéder à la page Détails de la règle.

  3. Cliquez sur Tester les modifications pour générer un rapport de simulation.

  4. Il peut s'écouler quelques heures avant que les modifications apportées aux métadonnées hiérarchiques soient reflétées dans le rapport de simulation pour les contraintes sur les paramètres de métadonnées de VM.

  5. Examinez le rapport pour reconfigurer les ressources non conformes ou demander des exemptions.

Valider avec une simulation

Le mode dry run consigne les cas de non-respect dans Cloud Logging, mais n'applique pas de restrictions.

Pour tester une contrainte, utilisez la commande gcloud org-policies set-policy comme suit :

  1. Créez un fichier YAML de règle (par exemple, dry-run-policy.yaml) avec un dryRunSpec :

    name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin
dryRunSpec:
  rules:
  - enforce: true

    Remplacez PROJECT_ID par l'ID du projet.

  2. Appliquez la règle :

    gcloud org-policies set-policy dry-run-policy.yaml

Application complète

Une fois que vous avez simulé et testé votre règle, vous pouvez l'appliquer à une ressource. La propagation des modifications des règles dans tous les systèmesCloud de Confiance by S3NS peut prendre jusqu'à 15 minutes.

Tester l'application des contraintes

Après avoir défini une règle, vous pouvez vérifier son application à l'aide de gcloud CLI. Par exemple, pour tester la contrainte compute.managed.requireOsLogin, procédez comme suit :

  1. Répertoriez les règles existantes pour confirmer votre configuration :

    gcloud org-policies list --project=PROJECT_ID

  2. Appliquez le règlement à l'aide d'un fichier YAML :

    gcloud org-policies set-policy enforce_managed_constraint.yaml

  3. Vérifiez l'application de la règle en appelant une API de mutation. La tentative de création d'une instance de VM avec des métadonnées non conformes devrait échouer :

    gcloud compute instances create VM_NAME \
    --machine-type=MACHINE_TYPE \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --metadata=enable-oslogin=false

    Remplacez les éléments suivants :

    • VM_NAME : nom de la nouvelle instance de VM.
    • MACHINE_TYPE : type de machine valide, par exemple e2-micro.
    • IMAGE_FAMILY : famille d'images valide, par exemple debian-11.
    • IMAGE_PROJECT : projet de la famille d'images, par exemple, debian-cloud.

  4. Vérifiez le message d'erreur. Un message de refus indiquant la contrainte spécifique enfreinte devrait s'afficher : ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Operation denied by org policy: [constraints/compute.managed.requireOsLogin].

Exemptions conditionnelles avec des tags

Vous pouvez utiliser des tags pour accorder des exceptions à des ressources spécifiques en fonction des besoins de l'entreprise. Dans cet exemple, nous utilisons un tag nommé osLoginOptional pour identifier les ressources exemptées de l'exigence de OS Login'exploitation. Lorsque vous associez ce tag à une valeur true à une ressource, la règle d'administration autorise l'existence de cette ressource spécifique sans qu'OS Login soit activé, même si la règle reste strictement appliquée au reste de votre environnement.

Pour accorder une exception à l'aide de tags, procédez comme suit :

  1. Créez un tag : utilisez la gcloud CLI pour créer une clé et une valeur de tag.

    1. Créez la clé de tag :

      gcloud resource-manager tags keys create osLoginOptional \
    --parent=organizations/ORGANIZATION_ID

    2. Créez la valeur de tag :

      gcloud resource-manager tags values create true \
    --parent=organizations/ORGANIZATION_ID/tagKeys/osLoginOptional

    Remplacez ORGANIZATION_ID par votre ID d'organisation.

  2. Associez le tag à une ressource. Pour exempter un projet de la contrainte compute.managed.requireOsLogin, associez le tag osLoginOptional=true au projet à l'aide de la commande gcloud resource-manager tags bindings create :

    gcloud resource-manager tags bindings create \
    --tag-value=ORGANIZATION_ID/osLoginOptional/true \
    --parent=//cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
    --location=global

    Remplacez ORGANIZATION_ID par l'ID de votre organisation et PROJECT_ID par l'ID du projet que vous souhaitez exempter.

    Pour savoir comment associer des tags à d'autres ressources, consultez Associer un tag à une ressource.

  3. Mettez à jour la règle : créez ou mettez à jour le fichier YAML de votre règle (par exemple, policy.yaml) pour inclure la règle conditionnelle.

    name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin
spec:
  rules:
  - condition:
      expression: "resource.matchTag('ORGANIZATION_ID/osLoginOptional', 'true')"
    enforce: false
  - enforce: true

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet.
    • ORGANIZATION_ID : votre ID d'organisation.

  4. Appliquez la règle : utilisez la commande gcloud CLI suivante pour activer la configuration :

    gcloud org-policies set-policy policy.yaml

Migration depuis les anciennes contraintes

Lors de la migration, notez que les contraintes gérées améliorent le comportement des anciennes règles, mais ne le reproduisent pas exactement. Les contraintes gérées offrent une meilleure prévisibilité en vérifiant les cas de non-respect uniquement lors des requêtes API qui créent ou modifient des ressources. Si une requête enfreint une contrainte, l'appel d'API échoue et renvoie une erreur claire. Cela diffère des anciennes règles, qui pouvaient être appliquées à différentes étapes d'une opération ou utilisées comme attributs de ressources, ce qui rendait le comportement d'application moins prévisible.

Lorsque vous passez d'une ancienne contrainte compute.* à une contrainte compute.managed.* moderne équivalente, suivez ces étapes pour éviter de restreindre involontairement les autorisations :

  1. Découverte : identifiez la nouvelle alternative de contrainte gérée.
  2. Analysez et validez : utilisez Policy Simulator et le mode de simulation, comme décrit précédemment.
  3. Appliquez la contrainte gérée : appliquez la nouvelle contrainte gérée en plus de l'ancienne.
  4. Supprimez les anciennes règles :
    • Accédez à l'inventaire des ressources dans la console Cloud de Confiance et filtrez par orgpolicy.Policy et par l'ancien nom de la contrainte pour identifier toutes les règles qui utilisent l'ancienne contrainte.
    • Supprimez toutes les règles qui utilisent l'ancienne contrainte. La suppression d'une règle rétablit le comportement par défaut géré par Google pour cette contrainte.

Étapes suivantes