This page explain how to use an organizationpolicy with your Cloud SQL project. To get started creatingorganization policies, seeAdd organization policies.

Overview

Organization policies let organization administrators set restrictions onhow users can configure instances under that organization. Organizationpolicies use rules, called constraints, that the organization administratorplaces on a project, folder, or organization. Constraints enforce the policyacross all instances. If, for example, you try to create an instance in an entitythat has an organization policy, the constraint runs a check to ensure theinstance configuration follows the requirements of the constraint. If the checkfails, Cloud SQL doesn't create the instance.

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

For more information about organization policies, seeOrganization Policy Service,Constraints, andHierarchy Evaluation.

The types of organization policies specific to Cloud SQL are as follows:

• Predefined organization policies
  • Connection organization policies
  • Customer-managed encryption keys (CMEK) organization policies
• Custom organization policies

Predefined organization policies

You can use the predefined constraints to control the public IP settings and Customer Managed Encryption Key (CMEK) settings of Cloud SQL instances. For more granular, customizable control over other supported settings, you can use custom constraints. For more information, seecustom organization policies.

Connection organization policies

Connection organization policies provide centralized control of the public IPsettings for Cloud SQL, to reduce the security attack surface ofCloud SQL instances from the Internet. An organization policyadministrator can use a connection policy to restrict public IP configurationsof Cloud SQL at the project, folder, or organization level.

Connection organization policy constraints

For the connection organization policy, there are two types of predefined constraints thatenforce access to Cloud SQL instances. There are alsocustom organization policies thatcan be used to enforce connection organization policies.For more information, see the ipConfiguration examples inexample custom constraints.

Restrictions for connection organization policies

When you set the organization policy for each project, you need to determine ifany one of the following apply to your project:

• Read replicas public IP conflicts
• Incompatibility usinggcloud CLI sql connect
• Google Cloud hosted services access
• Non-RFC 1918 private IP addresses

Read replicas public IP address conflicts

Cloud SQL read replicas connect to the primary instance over thenon-proxied database connection. You use the primary instanceAuthorized Networks setting to either explicitly or implicitly configurethe read replica public IP addresses.

If both the primary and replica instances are within the same region and enableprivate IP, there's no conflict with connection organization policy constraints.

Incompatibility usinggcloud sql connect

Thegcloud sql connect command uses a public IP address to connect toCloud SQL instances directly. Therefore, it is incompatible with thesql.restrictPublicIp constraint. This is generally a problem forinstances that use private IP.

In addition, thegcloud sql connect command doesn't use the proxy, making itincompatible with thesql.restrictAuthorizedNetworks constraint.

Instead, use the beta version of the command:

gcloudbetaauthlogingcloudbetasqlconnect[INSTANCE_ID]

This version uses the Cloud SQL Auth Proxy. Seegcloud beta sql connect forreference information.

The first time you run this command, you are prompted to install thegcloud CLICloud SQL Auth Proxy component. For that, you need to have write permission tothegcloud CLI SDK installation directory on your client machine.

Google Cloud hosted services access

If your application requires access to Cloud SQL instances from otherGoogle Cloud hosted services, such as App Engine, the application must use public IPaddresses. Don't enforce thesql.restrictPublicIpconstraint on the project. You can, however, enforcesql.restrictAuthorizedNetworks, as connections fromApp Engine go through the secure (proxied) connection.

Non-RFC 1918 private IP addresses

Connections to a Cloud SQL instance using a private IP address areautomatically authorized forRFC 1918address ranges. This lets all private clients access the database withoutgoing through the proxy. You must configure non-RFC 1918 address ranges asauthorized networks.

To use non-RFC 1918 private IP ranges that are not configured inthe authorized networks, you can take one or both of the following actions:

1. Don't enforcesql.restrictAuthorizedNetworks. If the authorizednetworks also enforcesql.restrictPublicIp, you can't configurethem in the console. Instead, use the Cloud SQL API or thegcloud CLI.
2. Use proxied connections for private IP instances.

Customer-managed encryption keys (CMEK) organization policies

Cloud SQL supports two organization policy constraints that help ensureCMEK protection across an organization:constraints/gcp.restrictNonCmekServicesandconstraints/gcp.restrictCmekCryptoKeyProjects.

Theconstraints/gcp.restrictNonCmekServices constraint requires CMEKprotection for thesqladmin.googleapis.com. When you add this constraint andadd thesqladmin.googleapis.com to theDeny policy list of services,Cloud SQL refuses to create new instances unless they are enabled withCMEK.

Theconstraints/gcp.restrictCmekCryptoKeyProjects constraint limits whichCloud KMS CryptoKeys to use for CMEK protection inCloud SQL for PostgreSQL instances. With this constraint, when Cloud SQLcreates a new instance with CMEK, the CryptoKey must come from an allowedproject, folder, or organization.

These constraints are only enforced on newly created Cloud SQL for PostgreSQLinstances.

For more overview information, seeCMEK organization policies.For information about CMEK organization policy constraints, seeOrganization policy constraints.

Custom organization policies

For granular, customizable control over the settings, you can createcustom constraints and use those customconstraints in a custom organization policy. You can use custom organization policies to improve your security, compliance, and governance.

To learn how to create custom organization policies, seeAdd custom organization policies. You can also view a list ofsupported fields for custom constraints.

Organization policy enforcement rules

Cloud SQL enforces the organization policy during the followingoperations:

• Instance creation
• Replica creation
• Instance restart
• Instance migration
• Instance clone

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

• A new policy has no effect on existing instances.
• An existing instance configuration remains valid, unless a user changesthe instance configuration from a compliance to non-compliance stateusing the Console,gcloud CLI, or RPC.
• A scheduled maintenance update doesn't cause a policy enforcement, becausemaintenance doesn't change the configuration of instances.

What's next

• Configuring organization policies.
• Learn about howprivate IP works with Cloud SQL.
• Learn how toconfigure private IP for Cloud SQL.
• Learn about theorganization policy service.
• Learn aboutorganization policy constraints.