This page describes AlloyDB for PostgreSQL organization policies, which organization administrators use to set restrictions on how users configure clusters and backups under that organization.
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 ensure 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 Key (CMEK) settings of 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 thealloydb.googleapis.com
API. When you add this constraint andalloydb.googleapis.com
to theDeny
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 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 ensure 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
- 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, gcloud 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
- Use predefined organization policies .
- Learn about how private IP works with AlloyDB.
- Learn how to configure private services for AlloyDB.
- Learn about the organization policy service .
- Learn about organization policy constraints .