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, Google Cloud 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 Google Cloud . 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 :

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Installez la Google Cloud CLI. Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante : 

      gcloud init

      Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

    2. Set a default region and zone.

    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. Une fois que la Google Cloud CLI est installée, initialisez-la en exécutant la commande suivante : 

      gcloud init

      Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à 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 Google Cloud .

  • 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 :

Contrainte Description
Paramètres de chiffrement de rattachement de VLAN autorisés

Cette contrainte de liste définit les paramètres de chiffrement autorisés pour les nouveaux rattachements de VLAN.
 Par défaut, les rattachements de VLAN peuvent utiliser n'importe quel paramètre de chiffrement.
 Définissez IPSEC comme seule valeur autorisée pour imposer la création de rattachements de VLAN chiffrés.

constraints/compute.managed.allowedVlanAttachmentEncryption
Bloquer les fonctionnalités en preview de Compute Engine

Cette contrainte garantit que les fonctionnalités en version preview sont bloquées, sauf si cette contrainte est explicitement autorisée. Une fois l'option "Autoriser" sélectionnée, vous pouvez contrôler les fonctionnalités d'aperçu qui peuvent être activées ou désactivées individuellement pour votre projet. Seules les fonctionnalités en preview activées sont accessibles dans le projet. Si vous désactivez ensuite la règle, l'état des fonctionnalités d'aperçu individuelles déjà définies ne change pas. Vous pouvez les désactiver individuellement. Cette contrainte ne s'applique qu'aux fonctionnalités de l'API Compute Alpha.

constraints/compute.managed.blockPreviewFeatures
Désactiver la virtualisation imbriquée des VM

[Aperçu public] Cette contrainte booléenne désactive la virtualisation imbriquée à accélération matérielle pour toutes les VM Compute Engine appartenant à l'organisation, au projet ou au dossier où cette contrainte est définie sur True.
Par défaut, la virtualisation imbriquée à accélération matérielle est autorisée pour toutes les VM Compute Engine s'exécutant sur Intel Haswell ou sur des plates-formes de processeurs plus récentes.

constraints/compute.managed.disableNestedVirtualization
Restreindre l'activation des métadonnées d'accès au port série des VM

Aperçu : cette contrainte empêche la clé de métadonnées serial-port-enable d'être définie sur "true" pour les VM Compute Engine de l'organisation, du projet ou du dossier où cette contrainte est appliquée. Par défaut, l'accès au port série peut être activé par VM, par zone ou par projet à l'aide de cette clé de métadonnées. Pour autoriser l'accès au port série pour des VM spécifiques, vous pouvez les exempter de cette règle à l'aide de tags et de règles conditionnelles.
Important : L'application de cette contrainte n'affecte pas les VM existantes pour lesquelles serial-port-enable est déjà défini sur "true". Elles conserveront l'accès, sauf si leurs métadonnées sont mises à jour.

constraints/compute.managed.disableSerialPortAccess
Désactiver la journalisation du port série des VM sur Stackdriver

[Aperçu public] Lorsqu'elle est appliquée, cette contrainte désactive la journalisation du port série sur Stackdriver à partir des VM Compute Engine.
Par défaut, la journalisation du port série est désactivée pour les VM Compute Engine. Vous pouvez l'activer de façon sélective par VM ou par projet à l'aide des attributs de métadonnées. La désactivation de la journalisation du port série peut empêcher certains services, comme les clusters Google Kubernetes Engine, de fonctionner correctement. Avant d'appliquer cette contrainte, vérifiez que les produits de votre projet ne dépendent pas de la journalisation du port série. Vous pouvez autoriser des instances de VM spécifiques à utiliser la journalisation du port série. Commencez par appliquer des tags pour marquer les instances, puis utilisez des règles conditionnelles basées sur les valeurs des tags pour exclure correctement ces instances de l'application des règles.

constraints/compute.managed.disableSerialPortLogging
Restreint l'utilisation du DNS interne global (gDNS) pour les projets dont le paramètre DNS est "ZonalOnly".

[Aperçu public] Cette contrainte, lorsqu'elle est appliquée, limite l'utilisation de gDNS. Cette restriction désactive la création de VM gDNS et la mise à jour des VM pour utiliser gDNS. La réversion d'un projet zDNS vers gDNS ne sera pas bloquée, mais entraînera l'application des règles en cas d'invocations ultérieures de l'API Instance.

constraints/compute.managed.disallowGlobalDns
OS Config obligatoire

[Aperçu public] Lorsqu'elle est appliquée, cette contrainte exige l'activation de VM Manager (OS Config) sur tous les nouveaux projets. Dans les projets nouveaux et existants, cette contrainte empêche les mises à jour de métadonnées qui ont pour effet de désactiver VM Manager au niveau du projet, de la zone du projet ou de l'instance. Vous pouvez autoriser des instances de VM spécifiques à désactiver VM Manager. Commencez par appliquer des tags pour marquer les instances, puis utilisez des règles conditionnelles basées sur les valeurs des tags pour exclure correctement ces instances de l'application des règles.

constraints/compute.managed.requireOsConfig
Exiger la connexion au système d'exploitation

[Aperçu public] Lorsqu'elle est appliquée, cette contrainte exige l'activation d'OS Login sur tous les projets nouvellement créés. Dans les projets nouveaux et existants, cette contrainte empêche les mises à jour de métadonnées qui ont pour effet de désactiver OS Login au niveau du projet, de la zone du projet ou de l'instance. Vous pouvez autoriser des instances de VM spécifiques à désactiver OS Login. Commencez par appliquer des tags pour marquer les instances, puis utilisez des règles conditionnelles basées sur les valeurs des tags pour exclure correctement ces instances de l'application des règles.

constraints/compute.managed.requireOsLogin
Restreint l'utilisation du transfert de protocole

Cette contrainte vous permet de limiter les types de déploiements de transfert de protocole (internes ou externes) pouvant être créés dans votre organisation. Pour configurer la contrainte, vous devez spécifier une liste d'autorisation des types de déploiement de transfert de protocole à autoriser. La liste d'autorisation ne peut inclure que les valeurs suivantes :

  • INTERNAL
  • EXTERNAL
. Par exemple, si la liste d'autorisation est définie sur "INTERNE", vos utilisateurs ne peuvent configurer que le transfert de protocole interne. En d'autres termes, toutes les règles de transfert associées aux instances cibles sont limitées au schéma d'équilibrage de charge INTERNAL et ne doivent utiliser que des adresses IP internes.

constraints/compute.managed.restrictProtocolForwardingCreationForTypes
Limiter le transfert IP de la VM

[Aperçu public] Cette contrainte définit si les instances de VM Compute Engine peuvent activer le transfert IP. Par défaut, si aucune règle n'est spécifiée, n'importe quelle VM peut activer le transfert IP dans n'importe quel réseau virtuel. Si elle est appliquée, cette contrainte empêchera la création ou la mise à jour d'instances de VM avec le transfert IP activé. Vous pouvez autoriser des instances de VM spécifiques à activer le transfert IP. Commencez par appliquer des tags pour marquer les instances, puis utilisez des règles conditionnelles basées sur les valeurs des tags pour exclure correctement ces instances de l'application des règles.

constraints/compute.managed.vmCanIpForward
Restreindre les adresses IP externes pour les instances de VM

[Aperçu public] Cette contrainte définit si les instances de VM Compute Engine sont autorisées à utiliser des adresses IP externes IPv4. Par défaut, toutes les instances de machines virtuelles sont autorisées à utiliser des adresses IP externes. Si elle est appliquée, cette contrainte empêchera la création ou la mise à jour d'instances de VM avec des adresses IP externes IPv4. Cette contrainte ne limite pas l'utilisation d'adresses IP externes IPv6. Vous pouvez autoriser des instances de VM spécifiques à utiliser des adresses IP externes IPv4. Commencez par appliquer des tags pour marquer les instances, puis utilisez des règles conditionnelles basées sur les valeurs des tags pour exclure correctement ces instances de l'application des règles.

constraints/compute.managed.vmExternalIpAccess

É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 ne se produit 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, zone, instance
compute.managed.requireOsLogin enable-oslogin Projet, zone, instance
compute.managed.disableGuestAttributesAccess enable-guest-attributes Projet, zone, instance
compute.managed.requireOsConfig enable-osconfig Projet, zone, 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 l'enfreignent. Procédez comme suit :

  1. Dans la console Google Cloud , 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 ne 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

Après avoir simulé et testé votre règle, vous pouvez l'appliquer à une ressource. La propagation des modifications des règles dans tous les systèmesGoogle Cloud 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 la règle d'application à l'aide d'un fichier YAML :

    gcloud org-policies set-policy enforce_managed_constraint.yaml

  3. Vérifiez l'application des règles 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 votre 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 de 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 à partir d'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 ne respecte pas une contrainte, l'appel d'API échoue et une erreur claire s'affiche. 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 renforcer involontairement les restrictions :

  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 Google Cloud 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