Configure networking, key management, encryption, and security

Manage Encryption and Key Lifecycle is the practice of protecting stored database data with customer-controlled keys and moving data with encrypted connections. Customer-Managed Encryption Keys (CMEK) stored in Cloud Key Management Service (KMS) (opens in a new tab) let the customer own the keys that encrypt data at rest, while Google operates the database service that depends on those keys. Mandatory Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protect traffic between applications and databases, so encryption covers both stored data and data in transit.

1.1Protecting Data at Rest with CMEK

Protecting data at rest with CMEK means stored data is encrypted with a key in the customer's Cloud KMS key ring instead of a Google-managed key alone. The database service depends on Cloud KMS for every encrypt and decrypt operation, so if the key is disabled, destroyed, or its permission is revoked, the database cannot read its own stored data. Enforcement checks that resource metadata references the customer key, which creates an ownership boundary where the customer controls access and the database controls use.

CMEK is applied at creation time to specific data scopes. The following resources each have a different enforcement point:

A Cloud SQL instance cannot be switched to CMEK after creation. To add CMEK, first create a new instance with CMEK enabled, then move the data over, and only after that delete the original instance.

1.2Managing the Cloud KMS Key Lifecycle

Managing the Cloud KMS key lifecycle means controlling how each key is generated, shared, stored, used, and retired under policy. Key-management policies require strong generation with an approved algorithm and protection level, secure distribution to services that need the key, and restricted access to the fewest custodians necessary. The system must also track all cryptographic material in compatible database services (opens in a new tab) and report changes in key status over time.

The lifecycle moves through ordered states:

1. Generation: Create the key in Cloud KMS with a defined protection level and encrypt-decrypt purpose, using an industry-accepted library and verified key-version algorithm.
2. Distribution: Securely share the key with supported database services through CMEK grants, so only authorized service accounts can call Cloud KMS to use it.
3. Storage and use: Store the key separately from the data it protects and use it for ongoing encryption while limiting access and monitoring use.
4. Retirement, replacement, or destruction: Retire the key at the end of its cryptoperiod, when its integrity is weakened, or when compromise is suspected, and never use a retired key for new encryption.

Secret and private keys must remain in protected form at all times:

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key and stored separately from it
• Within a secure cryptographic device, such as a hardware security module (HSM) or approved point-of-interaction device
• As at least two full-length key components or key shares, following an industry-accepted method

1.3Enforcing SSL and TLS for Data in Transit

Enforcing SSL and TLS for data in transit means every application-to-database connection must negotiate an encrypted session before data flows. Traffic flows from the database client across the network boundary to the database server, and the server accepts the connection only when both sides agree on a secure protocol version and valid credentials. Controls for AlloyDB and other databases require SSL encryption on the instance and enforce SSL for all incoming database connections.

The in-transit policy requires TLS 1.2 or higher and blocks fallback to insecure versions, algorithms, key sizes, or implementations. Only trusted keys and certificates are accepted, and each certificate must be confirmed as valid with no expiration or revocation. Restricting legacy TLS versions and insecure SSL policies keeps the trust boundary strong, so account data and other sensitive fields stay protected while moving over open or public networks.

Private connectivity and network isolation means giving a Cloud SQL (opens in a new tab) instance a private IP address inside a Virtual Private Cloud (VPC) so traffic stays on Google's internal network. Private Service Access (opens in a new tab) connects the customer's VPC network to Google's managed service network for Cloud SQL. The result is internal-only communication where applications and databases reach each other by private address, even across regions, with reduced public exposure.

2.1How Private Service Access Creates Isolation

Private Service Access is a private connection that relies on VPC Network Peering implemented internally by Google Cloud. The customer does not create the peering explicitly, but after the connection is created its underlying peering appears on the VPC Network Peering page. Traffic flows from resources in the customer VPC network to internal IP addresses of Cloud SQL resources in the Google-managed VPC network, and the boundary sits between those two peered networks. Private IP connections work across regions, but they do not work from legacy networks because legacy networks do not support VPC Network Peering or Private Service Access.

Setting up a new project for private IP requires an ordered network foundation before instance creation, otherwise creation fails with SERVICE_NETWORKING_NOT_ENABLED or NETWORK_NOT_PEERED:

1. Enable required APIs: Enable sqladmin.googleapis.com, compute.googleapis.com, and servicenetworking.googleapis.com in the project.
2. Allocate an IP range for peering: Create a global address with purpose VPC_PEERING, commonly with --prefix-length=16, on the selected VPC network.
3. Establish the peering connection: Connect the VPC network to servicenetworking.googleapis.com using the allocated range.

If Cloud SQL allocates the private range automatically, addresses for later instances in the same VPC network come from the same range. Each project has an internal limit on network-region combinations that can use Private Service Access, so reusing existing available networks helps avoid that limit.

2.2Connecting Multiple VPCs and Shared VPC Networks

Multiple-VPC connectivity is the problem of reaching one private Cloud SQL instance from more than one VPC network despite non-transitive peering. VPC Network Peering is not transitive, so routes are only shared between the two directly peered VPCs and a third VPC cannot use the original VPC's connection to reach Cloud SQL. The connection allows internal addresses to cross two VPC networks whether they belong to the same project or organization, but that trust does not extend further.

To connect a Cloud SQL instance to multiple VPCs with private addresses, use one of these documented patterns:

• Connect using custom advertised routes to export the private service routes to additional networks.
• Connect using an intermediate proxy, such as SOCKS5, that bridges traffic between networks.
• Connect using Cloud SQL Auth Proxy (opens in a new tab) as a service that forwards private traffic from another network.

Shared VPC extends the same private model across host and service projects in an organization. A new Cloud SQL instance can be created with a private IP address in a Shared VPC network, where the service project owns the instance and the host project owns the network. However, an existing Cloud SQL instance cannot later be assigned a private IP address in a Shared VPC network.

2.3Private IP Lifecycle Rules and Constraints

Private IP lifecycle rules define what can and cannot change after private connectivity is enabled on a Cloud SQL instance. A Cloud SQL instance can be configured for private IP at creation time or added to an existing instance, and public IP and private IP can be enabled together without affecting each other. Configuring an existing instance for private IP, or changing its connected network, restarts the instance and causes a few minutes of downtime.

Long-term operation is controlled by the following constraints:

• Private IP capability cannot be removed after it is configured on a Cloud SQL instance.
• A read replica inherits its private IP status from its primary instance, private IP cannot be configured directly on a replica, and no additional VPC private connection is needed for the replica.
• The incoming address of a Cloud SQL instance is static and does not change for both public and private IP, while the outgoing address is not always static except for outgoing public IP addresses of external server replicas, which are always static.
• An address range can be specified only for a primary instance, not for a read replica or clone.

2.4Secure Connection Paths for Private IP

Secure connection paths describe where the database client must run so private traffic never leaves the VPC boundary. Direct private connections and proxy-based connections both depend on the client having access to the same VPC network as the Cloud SQL instance. Serverless VPC Access provides a separate serverless path where supported serverless sources reach the instance directly without the proxy.

The Cloud SQL Auth Proxy path depends on placement and address selection because the proxy defaults to public IP when an instance has both IP types. Traffic flows from the application to the local proxy, then from the proxy to the instance private IP inside the peered VPC network, but only when the proxy host can reach that VPC and the private-only flag is supplied.

Enforce identity and perimeter security means combining who can act with where data can move. Identity and Access Management (IAM) (opens in a new tab) controls which users and service accounts can use database resources, while VPC Service Controls (opens in a new tab) and firewall rules define network boundaries that keep data from leaving trusted projects. Together these controls apply least privilege and mitigate data exfiltration for cloud databases.

3.1Apply Least Privilege With IAM

Identity and Access Management (IAM) is the system that governs who can access resources inside a security boundary, even when the request already comes from inside the perimeter. Least privilege means granting only the roles a user or service account needs to complete a task, at the smallest scope such as a project, instance, or dataset. Administrators setting up perimeters need specific IAM roles for administering VPC Service Controls, and all database users should have unused or excessive roles removed through role recommendations.

Strong credential practices support least privilege by reducing what a compromised identity can do. Organization policy constraints constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload block creation and upload of long-lived service account keys, with preference for short-lived credentials and more secure authentication alternatives. For remote server access, OS Login with 2-Step Verification requires SSH to Compute Engine to reauthenticate with a password or security key, so an attacker with stolen OAuth tokens but without the second factor is blocked before reaching database hosts.

3.2Define Service Perimeters With VPC Service Controls

VPC Service Controls is a resource-centric control that creates a service perimeter around explicitly specified Google Cloud projects and services to mitigate data exfiltration. Once a database project is inside a perimeter, its protected APIs will deny requests that cross the perimeter boundary unless an explicit exception allows them. The control applies to all user identities and service account identities, which makes it different from user-only controls that evaluate device or user conditions.

Securing a database project with VPC Service Controls follows an ordered workflow:

1. Select the project: Choose the Database Center or database project that the perimeter will protect and verify billing, required APIs, and IAM permissions.
2. Create the perimeter: Create a service perimeter and add the project to it.
3. Add instances: Add existing database instances to the perimeter by updating the perimeter configuration.
4. Restrict services: Add the required APIs as restricted services so data cannot be copied out through them.

3.3Restrict Services Inside the Perimeter

Restricted services are the APIs protected by a service perimeter, and data flows from the database to those services only when the services are inside the same boundary. To mitigate exfiltration from Database Center, the perimeter must restrict the Database Center API, Compute Engine API, Cloud Storage API, Container Registry API, Certificate Authority Service API, and Cloud KMS API. Adding databasecenter.googleapis.com as a restricted service protects the Database Center API, and the same principle applies to analytics services where both the API and its data sources must be protected. For example, protecting the Conversational Analytics API requires protecting geminidataanalytics.googleapis.com plus its sources such as bigquery.googleapis.com in the same perimeter.

3.4Control Outside Access With Access Levels

Access levels are optional exceptions that permit external access to protected resources inside a perimeter when specific conditions are met. An access level applies only to requests for protected resources coming from outside the service perimeter, such as an administrator connecting from an approved network or device. A request that uses compromised credentials but does not meet the defined IP, device, or certificate conditions is rejected at the boundary. User-centric controls such as Chrome Enterprise Premium complement this model by evaluating attributes like IP-based access or certificate-based mutual TLS on every API request for user identities.

3.5Harden Network Boundaries With Firewall Rules

Firewall rules (opens in a new tab) are network controls that allow or deny traffic to database servers and ports, and they form the first line of defense alongside intrusion detection and prevention. Firewalls enforce default-deny as the initial posture, so only explicitly allowed traffic can reach the system and unintentional access or leakage is prevented. Inside isolated environments, physically separate networks further divide duties, with an out-of-band management network for hardware administration accessible only to infrastructure operators and a data plane network for workload traffic. Private Google Access through restricted.googleapis.com keeps API traffic to Google services on the private path instead of the public internet.

With data exfiltration protection enabled, default policies deny broad movement by design:

• Allow inbound traffic only from the same project and deny all other inbound traffic.
• Allow outbound traffic only to destinations within the same organization and deny external traffic outside the organization.

When protection is disabled, outbound traffic to all destinations is allowed, so explicit egress policies are required to restrict it. Database hardening extends this approach to individual ports by blocking generic access from all IP addresses to database ports for MySQL, PostgreSQL, Oracle Database, MongoDB, Cassandra, and Redis, to access ports for SSH, RDP, Telnet, FTP, SMTP, POP3, HTTP, DNS, LDAP, and directory services, and to overly permissive firewall rules and external IP access on Compute Engine VM instances.

Key Facts

• Customer-Managed Encryption Keys (CMEK) in Cloud Key Management Service (KMS) encrypt data at rest, and if the key is disabled, destroyed, or revoked, the database cannot access its stored data.
• A Cloud SQL instance cannot gain CMEK after creation; a new CMEK-enabled instance must be created and data migrated to it.
• Private Service Access uses internally managed VPC Network Peering to give Cloud SQL a private IP, and VPC peering is not transitive to a third network.
• When a Cloud SQL instance has both public and private IP, the Cloud SQL Auth Proxy defaults to public IP unless started with -ip_address_types=PRIVATE.
• VPC Service Controls access levels allow outside-to-inside access when conditions are met, but never allow resources inside the perimeter to access data outside.