Présentation des règles d'administration

Grâce au service de règles d'administration, vous disposez d'un contrôle centralisé et automatisé sur les ressources Cloud de Confiance de votre organisation. En tant qu'administrateur des règles d'administration, vous pouvez configurer des contraintes sur l'ensemble de votre hiérarchie des ressources.

Avantages

  • Centralisez le contrôle pour configurer des restrictions sur l'utilisation des ressources de votre organisation.
  • Définissez et établissez des garde-fous pour que vos équipes de développement puissent respecter les limites de conformité.
  • Aidez les propriétaires de projet et leurs équipes à agir rapidement sans craindre de se soustraire à la conformité.

Cas d'utilisation courants

Les règles d'administration vous permettent d'effectuer les opérations suivantes :

Il existe de nombreuses autres contraintes qui vous permettent de contrôler avec précision les ressources de votre organisation. Pour en savoir plus, consultez la liste de toutes les contraintes liées aux règles d'administration.

Différences avec Identity and Access Management

Identity and Access Management se concentre sur la réponse à la question qui, et permet à l'administrateur d'autoriser une personne à prendre des mesures sur les ressources spécifiques en fonction des autorisations.

La règle d'administration met l'accent sur la réponse à la question quoi, et permet à l'administrateur de définir des restrictions sur des ressources spécifiques afin de déterminer leur configuration.

Fonctionnement des règles d'entreprise

Une règle d'administration configure une seule contrainte qui restreint un ou plusieurs services Cloud de Confiance . La règle d'administration est définie sur une ressource d'organisation, de dossier ou de projet pour appliquer la contrainte à cette ressource et à toutes les ressources enfants.

Une règle d'administration contient une ou plusieurs règles qui spécifient comment et si la contrainte doit être appliquée. Par exemple, une règle d'administration peut contenir une règle qui applique la contrainte uniquement aux ressources taguées environment=development et une autre règle qui empêche l'application de la contrainte à d'autres ressources.

Les descendants de la ressource à laquelle la règle d'administration est associée héritent de la règle d'administration. En appliquant une règle d'administration à la ressource Organisation, l'administrateur des règles d'administration peut contrôler l'application de cette règle et la configuration des restrictions dans l'ensemble de votre organisation.

Concepts de règle d'administration

Contraintes

Une contrainte est un type particulier de restriction sur un Cloud de Confiance service ou une liste de Cloud de Confiance services. On peut la considérer comme un modèle définissant les comportements à contrôler. Par exemple, vous pouvez empêcher les ressources de projet d'accéder aux ressources de stockage Compute Engine à l'aide de la contrainte compute.storageResourceUseRestrictions.

Ce modèle est ensuite défini sur une ressource de votre hiérarchie des ressources en tant que règle d'administration, qui applique les règles définies dans la contrainte. Le service Cloud de Confiance mappé sur cette contrainte et associé à cette ressource applique les restrictions configurées dans la règle d'administration.

Une règle d'administration est définie dans un fichier YAML ou JSON par la contrainte qu'elle applique et, éventuellement, par les conditions dans lesquelles la contrainte est appliquée. Chaque règle d'administration applique exactement une contrainte en mode actif, en mode de simulation ou dans les deux.

Les anciennes contraintes gérées comportent une ou plusieurs règles de liste ou règles booléennes en fonction du type de contrainte. Les règles de liste sont un ensemble de valeurs autorisées ou refusées. Les règles booléennes peuvent autoriser toutes les valeurs, refuser toutes les valeurs ou déterminer si une contrainte est appliquée ou non.

Contraintes gérées (ancienne version)

Les anciennes contraintes gérées ont un type de contrainte de liste ou booléen, qui détermine les valeurs pouvant être utilisées pour vérifier l'application. Le serviceCloud de Confiance responsable de l'application de la contrainte évalue le type et les valeurs qui lui sont associés pour déterminer la restriction appliquée.

Ces anciennes contraintes étaient auparavant appelées contraintes prédéfinies.

Lister les règles

Les anciennes contraintes gérées avec des règles de liste autorisent ou interdisent une liste de valeurs définies dans une règle d'administration. Ces anciennes contraintes étaient auparavant appelées contraintes de liste. La liste des valeurs autorisées ou refusées est exprimée sous forme de chaîne de sous-arborescence hiérarchique. La chaîne de sous-arborescence spécifie le type de ressource auquel elle s'applique. Par exemple, la contrainte gérée ancienne constraints/compute.trustedImageProjects accepte une liste d'ID de projet sous la forme projects/PROJECT_ID.

Vous pouvez spécifier que toutes les valeurs sont autorisées, que toutes les valeurs sont refusées ou qu'une liste spécifique de valeurs est autorisée ou refusée. Lorsque vous spécifiez une liste de valeurs autorisées ou refusées, la règle d'administration évalue implicitement que seules ces valeurs sont autorisées ou refusées. Par exemple, si vous avez une contrainte qui n'autorise que projects/PROJECT_ID, toutes les autres valeurs sont implicitement refusées.

Les valeurs peuvent recevoir un préfixe sous la forme prefix:value pour les contraintes qui les acceptent, ce qui confère à la valeur un sens supplémentaire, par exemple :

  • is: : applique une comparaison par rapport à la valeur exacte. Ce comportement est le même que celui applicable en l'absence de préfixe ; il est requis lorsque la valeur inclut le caractère deux-points.

  • under: : applique une comparaison à la valeur et à toutes ses valeurs enfants. Si une ressource est autorisée ou refusée via ce préfixe, ses ressources enfants le seront également. La valeur fournie doit correspondre à l'ID d'une ressource d'organisation, de dossier ou de projet.

  • in: : applique une comparaison à toutes les ressources qui incluent cette valeur. Par exemple, vous pouvez ajouter in:us-locations à la liste des valeurs refusées de la contrainte constraints/gcp.resourceLocations pour bloquer tous les emplacements inclus dans la région us.

Si aucune liste de valeurs n'est fournie ou si la règle d'administration est définie sur la valeur par défaut gérée par Google, le comportement par défaut de la contrainte prend effet, ce qui autorise ou refuse toutes les valeurs.

La règle d'organisation suivante applique une ancienne contrainte gérée qui autorise les instances de VM Compute Engine vm-1 et vm-2 dans organizations/1234567890123 à accéder aux adresses IP externes :

name: organizations/1234567890123/policies/compute.vmExternalIpAccess
spec:
  rules:
  - values:
      allowedValues:
      - is:projects/project_a/zones/us-central1-a/instances/vm-1
      - is:projects/project_b/zones/us-central1-a/instances/vm-2

Règles booléennes

Une ancienne contrainte gérée avec une règle booléenne est appliquée ou non. Par exemple, constraints/compute.disableSerialPortAccess a deux états possibles :

  • Appliquée : la contrainte est appliquée et l'accès au port série n'est pas autorisé.
  • Non appliquée : la contrainte disableSerialPortAccess n'est ni appliquée ni vérifiée, l'accès au port série est donc autorisé.

Si la règle d'administration est définie sur la valeur par défaut gérée par Google, le comportement par défaut de la contrainte prend effet.

Ces anciennes contraintes étaient auparavant appelées contraintes booléennes.

La règle d'administration suivante applique une ancienne contrainte gérée qui désactive la création de comptes de service externes dans organizations/1234567890123 :

name: organizations/1234567890123/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

Règles d'administration conditionnelles

Les tags permettent d'appliquer des contraintes de manière conditionnelle selon qu'une ressource possède un tag spécifique ou non. Vous pouvez utiliser des tags et l'application conditionnelle de contraintes pour fournir un contrôle centralisé des ressources de votre hiérarchie.

Pour en savoir plus sur les tags, consultez la page Présentation des tags. Pour découvrir comment définir une règle d'administration conditionnelle à l'aide de tags, consultez Définir le champ d'règles d'administration avec des tags.

Héritage

Lorsqu'une règle d'administration est définie sur une ressource, tous les descendants de cette ressource héritent de la règle d'administration par défaut. Si vous définissez une règle d'administration sur la ressource Organisation, tous les dossiers enfants, projets et ressources de service héritent de la configuration de ces restrictions telle que définie par la règle.

Vous pouvez définir une règle d'administration sur une ressource descendante qui écrase l'héritage ou hérite de la règle d'administration de la ressource parente. Les règles d'administration qui appliquent des contraintes gérées anciennes sont fusionnées en fonction des règles d'évaluation de la hiérarchie. Ce système permet de contrôler précisément l'application des règles d'administration d'administration dans votre organisation ainsi que les emplacements où vous souhaitez créer des exceptions.

Pour en savoir plus, consultez Évaluation hiérarchique.

Cas de non-respect

Un non-respect survient lorsqu'un service Cloud de Confiance agit ou se trouve dans un état opposé à la configuration de la restriction de la règle d'administration dans le champ d'application de sa hiérarchie des ressources. Cloud de Confiance Les services appliquent des contraintes pour empêcher le non-respect des règles, mais l'application de nouvelles règles d'administration d'administration n'est généralement pas rétroactive. Si une contrainte liée à une règle d'administration est appliquée de manière rétroactive, elle est libellée comme telle sur la page Contraintes liées aux règles d'administration.

Si une nouvelle règle d'administration définit une restriction applicable à une action ou un état dans lequel un service est déjà engagé, la règle est considérée comme étant non respectée, mais le service ne met pas fin à son comportement actuel. Vous devrez traiter ce non-respect manuellement. Cela évite le risque qu'une nouvelle règle d'administration arrête complètement la continuité de votre activité.

Étapes suivantes