AlloyDB organization policies overview

To enforce consistent security and governance restrictions on how users configure AlloyDB for PostgreSQL clusters, instances, and backups across your organization, you can configure organization policies.

Projects, folders, and organizations are container resources organized in a parent-child resource hierarchy. An organization is the root node in that hierarchy. For more information, see Resource hierarchy.

Organization policies contain rules, called constraints, that the organization administrator places on a project, folder, or organization. Constraints enforce a policy across all clusters and backups. For example, if you try to create a cluster or backup in an entity that has an organization policy, the constraint runs a check to verify that the cluster or backup configuration follows the requirements of the constraint. If the check fails, AlloyDB doesn't create the cluster or backup resource.

When you add projects to an organization or folder that uses an organization policy, the projects inherit the constraints of that policy.

For more information about organization policies, see Introduction to the Organization Policy Service, Constraints, and Understanding hierarchy evaluation.

The following organization policies are specific to AlloyDB:

Predefined organization policies

To get started, you can use customer-managed encryption keys (CMEK) settings on AlloyDB clusters and backups. For more details, see Use predefined organization policies. For granular, customizable control over other supported settings, use custom constraints. For more information, see Use custom organization policies.

Customer-managed encryption keys (CMEK) organization policies

AlloyDB supports the following organization policy constraints:

  • constraints/gcp.restrictNonCmekServices: requires CMEK protection for the alloydb.googleapis.com API. When you add this constraint and alloydb.googleapis.com to the Deny policy list of services, AlloyDB refuses to create a new cluster or a backup resource unless the new cluster or backup resource is enabled with CMEK.

  • constraints/gcp.restrictCmekCryptoKeyProjects: limits which Cloud Key Management Service (Cloud KMS) CryptoKeys to use for CMEK protection in AlloyDB clusters and backups. When AlloyDB creates a new cluster or backup using CMEK and this constraint, the CryptoKey must come from an allowed project, folder, or organization.

These constraints help enforce CMEK protection across an organization, and are only enforced on newly created AlloyDB clusters and backups. For more information, see CMEK organization policies and Organization policy constraints.

Custom organization policies

For granular, customizable control over the settings, you can create custom constraints and use them in a custom organization policy. Use custom organization policies to improve your security, compliance, and governance.

To learn how to create custom organization policies, see Use custom organization policies. You can also view a list of supported custom constraints and operations.

Organization policy enforcement rules

AlloyDB enforces the organization policy for the following operations:

  • Instance creation

  • Instance update

  • Cluster creation

  • Cluster update

  • Backup creation

Like all organization policy constraints, policy changes don't apply retroactively to existing clusters and backups. The following are examples:

  • A new policy has no effect on existing instances, clusters, or backups.
  • Unless a user changes the instance, cluster, or backup configuration from a compliance to non-compliance state using the Google Cloud console, Google Cloud CLI, or RPC, an existing instance, cluster, or backup configuration remains valid.
  • A scheduled maintenance update doesn't cause policy enforcement because maintenance doesn't change the configuration of instances, clusters, or backups.

What's next