Organization policies

This page provides information about custom organization policies and constraints, and how to create them with your AlloyDB for PostgreSQL project.

Overview

Organization policies in AlloyDB provide centralized controls that help you manage and secure AlloyDB instances across your entire Google Cloud organization or within specific folders and projects.

By implementing a custom organization policy you enforce consistent configurations and restrictions. This ensures that your AlloyDB instances adhere to security best practices and regulatory requirements.

If you attempt to create or update an instance while the custom constraint is enforced, then the operation fails. Any project added to the organization or folder that uses a custom organization policy inherits the constraints of that policy.

For more information about organization policies, see the following resources:

Restrict public IP access using organization policies

Organization policies are defined by the values set for each constraint. An organization policy administrator can create custom constraints to restrict public IP configurations of AlloyDB at the project, folder, or organization level.

You can create a custom constraint—for example, customConstraints/custom.restrictPublicIP, to limit public IP access on AlloyDB instances. This boolean constraint restricts configuring public IP on AlloyDB instances where this constraint is set. This constraint isn't retroactive. AlloyDB instances with existing public IP access still work even after this constraint is enforced.

By default, public IP access to AlloyDB instances is allowed.

To create and enforce a custom constraint on your organization policy, complete the following steps:

  1. Create a YAML configuration that prevents you from enabling public IP when you create or update an AlloyDB instance.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.CONSTRAINT_NAME
resourceTypes:
- alloydb.googleapis.com/Instance
methodTypes:
- CREATE
- UPDATE
condition: "resource.networkConfig.enablePublicIp == true"
actionType: DENY
displayName: Restrict public IP access on AlloyDB instances
description: Prevent users from enabling public IP on instance creation and update

    Replace the following:

    • ORGANIZATION_ID: the organization ID you want to apply the constraint to.

    • CONSTRAINT_NAME: the name of the custom constraint—for example, restrictPublicIP.

  2. Use the gcloud org-policies command to enforce the constraint.

    gcloud org-policies set-custom-constraint CONSTRAINT_YAML_PATH

    Replace CONSTRAINT_YAML_PATH with full path to your constraint file—for example, /home/user/customconstraint.yaml.

  3. Verify if the constraint is set in the policy.

    gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

  4. Create a policy YAML configuration file.

    name: projects/PROJECT_ID/policies/custom.CONSTRAINT_NAME
spec:
  rules:
  - enforce: true

    Replace the following:

    • PROJECT_ID: the project ID on which you want to enforce your constraint.
    • CONSTRAINT_NAME: the name of the constraint created earlier—for example, restrictPublicIP.

  5. Use the gcloud org-policies set-policy command to enforce the constraint.

    gcloud org-policies set-policy POLICY_YAML_PATH

    Replace POLICY_YAML_PATH with full path to your policy file—for example, /home/user/custompolicy.yaml.

For more information about adding custom constraints to the organization policy, see Creating and managing custom organization policies.

Supported AlloyDB operations

AlloyDB enforces the organization policy during the following operations:

  • Instance creation
  • Instance update

Like all organization policy constraints, policy changes don't apply retroactively to existing instances.

  • A new policy doesn't impact existing instance configurations.
  • An existing instance configuration remains valid, unless you change the instance configuration from a compliance to non-compliance state using the Console, Google Cloud CLI CLI, or RPC.
  • A scheduled maintenance update doesn't cause a policy enforcement, because maintenance doesn't change the configuration of instances.

What's next