Présentation des règles d'administration AlloyDB

Cette page décrit les règles d'administration AlloyDB pour PostgreSQL, que les administrateurs d'organisation utilisent pour définir des restrictions sur la façon dont les utilisateurs configurent les clusters et les sauvegardes au sein de cette organisation.

Les projets, les dossiers et les organisations sont des ressources de conteneur organisées dans une hiérarchie de ressources parent-enfant. Une organisation est le nœud racine de cette hiérarchie. Pour en savoir plus, consultez la section Hiérarchie des ressources.

Les règles d'administration contiennent des règles, appelées contraintes, que l'administrateur place sur un projet, un dossier ou une organisation. Les contraintes appliquent une règle à tous les clusters et à toutes les sauvegardes. Par exemple, si vous essayez de créer un cluster ou une sauvegarde dans une entité dotée d'une règle d'administration, la contrainte exécute une vérification pour s'assurer que la configuration du cluster ou de la sauvegarde respecte les exigences de la contrainte. Si la vérification échoue, AlloyDB ne crée pas le cluster ni la ressource de sauvegarde.

Lorsque vous ajoutez des projets à une organisation ou un dossier qui utilise une règle d'administration, les projets héritent des contraintes de cette règle.

Pour en savoir plus sur les règles d'administration, consultez Présentation du service de règles d'administration, Contraintes et Comprendre l'évaluation hiérarchique.

Les règles d'administration suivantes sont spécifiques à AlloyDB :

Règles d'administration prédéfinies

Pour commencer, vous pouvez utiliser les paramètres de clé de chiffrement gérée par le client (CMEK) des clusters et des sauvegardes AlloyDB. Pour en savoir plus, consultez Utiliser des règles d'administration prédéfinies. Pour un contrôle précis et personnalisable des autres paramètres compatibles, utilisez des contraintes personnalisées. Pour en savoir plus, consultez Utiliser des règles d'administration personnalisées.

Règles d'administration des clés de chiffrement gérées par le client (CMEK)

AlloyDB est compatible avec les contraintes de règle d'administration suivantes :

  • constraints/gcp.restrictNonCmekServices : nécessite une protection CMEK pour l'API alloydb.googleapis.com. Lorsque vous ajoutez cette contrainte et alloydb.googleapis.com à la liste des services de la règle Deny, AlloyDB refuse de créer un cluster ou une ressource de sauvegarde, sauf si le nouveau cluster ou la nouvelle ressource de sauvegarde sont activés avec CMEK.
  • constraints/gcp.restrictCmekCryptoKeyProjects : limite les CryptoKeys Cloud KMS à utiliser pour la protection CMEK dans les clusters et les sauvegardes AlloyDB. Lorsque AlloyDB crée un cluster ou une sauvegarde avec CMEK et cette contrainte, la CryptoKey doit provenir d'un projet, d'un dossier ou d'une organisation autorisée.

Ces contraintes permettent d'assurer la protection CMEK dans l'ensemble d'une organisation. Elles ne sont appliquées qu'aux clusters et aux sauvegardes AlloyDB nouvellement créés. Pour en savoir plus, consultez Règles d'administration CMEK et Contraintes liées aux règles d'administration.

Règles d'administration personnalisées

Pour un contrôle précis et personnalisable des paramètres, vous pouvez créer des contraintes personnalisées et les utiliser dans une règle d'administration personnalisée. Utilisez des règles d'administration personnalisées pour améliorer votre sécurité, votre conformité et votre gouvernance.

Pour savoir comment créer des règles d'administration personnalisées, consultez Utiliser des règles d'administration personnalisées. Vous pouvez également afficher la liste des opérations et contraintes personnalisées compatibles.

Règles d'application des règles d'administration

AlloyDB applique la règle d'administration pour les opérations suivantes :

  • Création d'une instance
  • Mise à jour de l'instance
  • Création du cluster
  • Créer une sauvegarde

Comme pour toutes les contraintes des règles d'administration, les modifications apportées aux règles ne s'appliquent pas rétroactivement aux clusters et aux sauvegardes existants. Voici quelques exemples :

  • Une nouvelle règle n'a aucun effet sur les instances, les clusters ni les sauvegardes existants.
  • Une configuration d'instance, de cluster ou de sauvegarde existante reste valide, sauf si un utilisateur la modifie en passant d'un état de conformité à un état de non-conformité à l'aide de la console Google Cloud , de gcloud CLI ou de RPC.
  • Une mise à jour de maintenance planifiée n'entraîne pas l'application des règles, car la maintenance ne modifie pas la configuration des instances, des clusters ni des sauvegardes.

Étapes suivantes