This page explain how to use an organization policy with your Cloud SQL project. To get started creating organization policies, see Add organization policies.
Organization policies let organization administrators set restrictions on how users can configure instances under that organization. Organization policies use rules, called constraints, that the organization administrator places on a project, folder, or organization. Constraints enforce the policy across all instances. If, for example, you try to add an instance to an entity that has an organization policy, the constraint runs a check to ensure the instance configuration follows the requirements of the constraint. If the check fails, Cloud SQL doesn't create the instance.
As you add projects to an organization or folder that uses an organization policy, the projects inherit the constraints of that policy.
There are two types of organization policies specific to Cloud SQL:
Connection organization policies
Connection organization policies provide centralized control of the public IP settings for Cloud SQL, to reduce the security attack surface of Cloud SQL instances from the Internet. An organization policy administrator can use a connection policy to restrict public IP configurations of Cloud SQL at the project, folder, or organization level.
Connection organization policy constraints
For the connection organization policy, there are two types of constraints that enforce access to Cloud SQL instances.
|Restrict public IP access on Cloud SQL instances|| This boolean constraint restricts configuring public IP
on Cloud SQL instances where this constraint is set to
By default, public IP access to Cloud SQL instances is allowed.
|Restrict Authorized Networks on Cloud SQL instances|| When set to
By default, you can add Authorized Networks to Cloud SQL instances.
Restrictions for connection organization policies
When you set the organization policy for each project, you need to determine if any one of the following apply to your project:
- Read replicas public IP conflicts
- Incompatibility using gcloud sql connect
- GCP hosted services access
- MySQL failover replica public IP conflicts
- Non-RFC 1918 private IP addresses
Read replicas public IP address conflicts
Cloud SQL read replicas connect to the primary instance over the non-proxied database connection. You use the primary instance Authorized Networks setting to either explicitly or implicitly configure the read replica public IP addresses.
If both the primary and replica instances are within the same region and enable private IP, there's no conflict with connection organization policy constraints.
gcloud sql connect
gcloud sql connect command uses a public IP address to connect to
Cloud SQL instances directly. Therefore, it is incompatible with the
sql.restrictPublicIp constraint. This is generally a problem for
instances that use private IP.
In addition, the
gcloud sql connect command doesn't use the proxy, making it
incompatible with the
Instead, use the beta version of the command:
gcloud beta auth login gcloud beta sql connect [INSTANCE_ID]
This version uses the Cloud SQL Auth proxy. See
gcloud beta sql connect for
The first time you run this command, you are prompted to install the gcloud Cloud SQL Auth proxy component. For that, you need to have write permission to the gcloud SDK installation directory on your client machine.
GCP hosted services access
If your application requires access to Cloud SQL instances from other
GCP hosted services, such as App Engine, the application must use public IP
addresses. Don't enforce the
constraint on the project. You can, however, enforce
sql.restrictAuthorizedNetworks, as connections from
App Engine go through the secure (proxied) connection.
MySQL failover replica public IP conflicts
A MySQL failover replica acts the same as a read replica for connection organization policies. If both the primary and replica instances are within the same region and enable private IP, there's no conflict with connection organization policy constraints.
Non-RFC 1918 private IP addresses
Connections to a Cloud SQL instance using a private IP address are automatically authorized for RFC 1918 address ranges. This lets all private clients access the database without going through the proxy. You must configure non-RFC 1918 address ranges as authorized networks.
To use non-RFC 1918 private IP ranges that are not configured in the authorized networks, you can take one or both of the following actions:
- Don't enforce
sql.restrictAuthorizedNetworks. If the authorized networks also enforce
sql.restrictPublicIp, you can't configure them in the console. Instead, use the Cloud SQL API or the gcloud.
- Use proxied connections for private IP instances.
Known Issues for connection organization policies
Restrict Authorized Networks constraint
For Cloud SQL instances that have a pre-existing Authorized Networks entry, additional Authorized Networks entries are allowed, even when using the Restrict Authorized Networks (sql.restrictAuthorizedNetworks) constraint. This also affects instances that have enabled readonly or failover replicas, because they have an Authorized Networks entry for the replica that isn't visible to the user.
This known issue will be removed when the constraint only allows the removal, not the addition, of Authorized Networks entries.
Customer-managed encryption keys (CMEK) organization policies
Cloud SQL supports two organization policy constraints that help ensure
CMEK protection across an organization:
constraints/gcp.restrictNonCmekServices constraint requires CMEK
protection for the
sqladmin.googleapis.com. When you add this constraint and
sqladmin.googleapis.com to the
Deny policy list of services,
Cloud SQL refuses to create new instances unless they are enabled with
constraints/gcp.restrictCmekCryptoKeyProjects constraint limits which
Cloud KMS CryptoKeys to use for CMEK protection in
Cloud SQL for MySQL instances. With this constraint, when Cloud SQL
creates a new instance with CMEK, the CryptoKey must come from an allowed
project, folder, or organization.
These constraints are only enforced on newly created Cloud SQL for MySQL instances.
Organization policy enforcement rules
Cloud SQL enforces the organization policy during the following operations:
- Instance creation
- Replica creation
- Instance restart
- Instance migration
- Instance clone
Like all organization 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 changes the instance configuration from a compliance to non-compliance state using the Console, gcloud, or RPC.
- A scheduled maintenance update doesn't cause a policy enforcement, because maintenance doesn't change the configuration of instances.
- Configuring organization policies.
- Learn about how private IP works with Cloud SQL.
- Learn how to configure private IP for Cloud SQL.
- Learn about the organization policy service.
- Learn about organization policy constraints.