This page describes how to enforce SSL/TLS encryption for an instance to ensure that all connections are encrypted. You can also learn more about how Cloud SQL uses self-managed SSL/TLS certificates to connect to Cloud SQL instances securely.
OverviewCloud SQL creates a server certificate automatically when you create your instance. We recommend that you enforce all connections to use SSL/TLS.
SQL Server only performs certificate verification when the client request explicitly specifies that it requires an encrypted connection. In this case the
server certificatemust be installed on the client machine. Otherwise, clients are able to freely connect with no additional changes to their connection strings or certificates, even if you configure the instance with
sslMode
set to
ENCRYPTED_ONLY
.
For more information, see the Enable encrypted connections to the Database Engine section in the SQL Server documentation.
If you enforce SSL for an instance, then the instance requires a restart. A restart might also be required after you change SSL/TLS certificates. When a restart is required, Cloud SQL automatically restarts the instance for you. The restart of an instance can incur downtime.
Enforce SSL/TLS encryptionYou can use the SSL mode setting to enforce SSL encryption in the following ways:
Allow both non-SSL/non-TLS and SSL/TLS connections. This is the default.
Only allow connections encrypted with SSL/TLS.
If you select Allow non-SSL/non-TLS and SSL/TLS connections for your Cloud SQL instance, SSL/TLS connections are accepted, as well as unencrypted and unsecure connections. If you do not require SSL/TLS for all connections, unencrypted connections are still allowed. For this reason, if you are accessing your instance using public IP, we strongly recommend that you enforce SSL for all connections.
You can connect either directly to instances by using SSL/TLS certificates, or you can connect by using the Cloud SQL Auth Proxy or Cloud SQL Connectors. If you connect by using Cloud SQL Auth Proxy or Cloud SQL Connectors, then the connections are automatically encrypted with SSL/TLS. With Cloud SQL Auth Proxy and Cloud SQL Connectors, client and server identities are also automatically verified regardless of the SSL mode setting.
Note: We recommend that you update instances using SSL mode instead of using the legacyrequire-ssl parameter. If you update the SSL enforcement configuration on an existing instance, make sure that the values don't conflict with the require-ssl parameter.
Enforcing SSL ensures that all connections are encrypted.
Note: The Cloud SQL Auth Proxy or Cloud SQL Connectors add another layer of encryption besides SQL Server's built-in encryption. In other words, the connection between the Proxy Client/Cloud SQL Connectors and the Proxy Server would be double-encrypted. Double encryption can negatively impact SQL Server performance. We suggest that customers consider carefully before enforcing SSL and using Cloud SQL Auth Proxy or Cloud SQL Connectors at the same time.To enable requiring SSL/TLS, do the following:
ConsoleIn the Google Cloud console, go to the Cloud SQL Instances page.
gcloud sql instances patch INSTANCE_NAME \ --ssl-mode=SSL_ENFORCEMENT_MODE
Replace SSL_ENFORCEMENT_MODE with one of the following options:
ALLOW_UNENCRYPTED_AND_ENCRYPTED allows non-SSL/non-TLS and SSL/TLS connections. This is the default value.ENCRYPTED_ONLY only allows connections encrypted with SSL/TLS.To enforce SSL/TLS encryption, use a Terraform resource:
Apply the changesTo apply your Terraform configuration in a Google Cloud project, complete the steps in the following sections.
Prepare Cloud ShellSet the default Google Cloud project where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform configuration file.
Each Terraform configuration file must have its own directory (also called a root module).
.tf extension—for example main.tf. In this tutorial, the file is referred to as main.tf.
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created main.tf.
Optionally, copy the code from GitHub. This is recommended when the Terraform snippet is part of an end-to-end solution.
terraform init
Optionally, to use the latest Google provider version, include the -upgrade option:
terraform init -upgrade
terraform plan
Make corrections to the configuration as necessary.
yes at the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
To delete your changes, do the following:
deletion_protection argument to false.
deletion_protection = "false"
yes at the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following command and entering yes at the prompt:
terraform destroy
Before using any of the request data, make the following replacements:
ALLOW_UNENCRYPTED_AND_ENCRYPTED: allows non-SSL/non-TLS and SSL/TLS connections.ENCRYPTED_ONLY: only allows connections encrypted with SSL/TLS.HTTP method and URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Request JSON body:
{
"settings": {
"ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"}
}
}
To send your request, expand one of these options:
curl (Linux, macOS, or Cloud Shell) Note: The following command assumes that you have logged in to thegcloud CLI with your user account by running gcloud init or gcloud auth login , or by using Cloud Shell, which automatically logs you into the gcloud CLI . You can check the currently active account by running gcloud auth list.
Save the request body in a file named request.json, and execute the following command:
curl -X PATCH \PowerShell (Windows) Note: The following command assumes that you have logged in to the
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"
gcloud CLI with your user account by running gcloud init or gcloud auth login . You can check the currently active account by running gcloud auth list.
Save the request body in a file named request.json, and execute the following command:
$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }Invoke-WebRequest `
-Method PATCH `
-Headers $headers `
-ContentType: "application/json; charset=utf-8" `
-InFile request.json `
-Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content
You should receive a JSON response similar to the following:
Response{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-20T21:30:35.667Z",
"operationType": "UPDATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_ID",
"selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
Before using any of the request data, make the following replacements:
ALLOW_UNENCRYPTED_AND_ENCRYPTED: allows non-SSL/non-TLS and SSL/TLS connections.ENCRYPTED_ONLY: only allows connections encrypted with SSL/TLS.HTTP method and URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Request JSON body:
{
"settings": {
"ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"}
}
}
To send your request, expand one of these options:
curl (Linux, macOS, or Cloud Shell) Note: The following command assumes that you have logged in to thegcloud CLI with your user account by running gcloud init or gcloud auth login , or by using Cloud Shell, which automatically logs you into the gcloud CLI . You can check the currently active account by running gcloud auth list.
Save the request body in a file named request.json, and execute the following command:
curl -X PATCH \PowerShell (Windows) Note: The following command assumes that you have logged in to the
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"
gcloud CLI with your user account by running gcloud init or gcloud auth login . You can check the currently active account by running gcloud auth list.
Save the request body in a file named request.json, and execute the following command:
$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }Invoke-WebRequest `
-Method PATCH `
-Headers $headers `
-ContentType: "application/json; charset=utf-8" `
-InFile request.json `
-Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content
You should receive a JSON response similar to the following:
Response{
"kind": "sql#operation",
"targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
"status": "PENDING",
"user": "user@example.com",
"insertTime": "2020-01-20T21:30:35.667Z",
"operationType": "UPDATE",
"name": "OPERATION_ID",
"targetId": "INSTANCE_ID",
"selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
"targetProject": "PROJECT_ID"
}
Cloud SQL creates a server certificate automatically when you create your instance. As long as the server certificate is valid, you don't need to actively manage your server certificate. Cloud SQL lets you select between three different certificate authority (CA) hierarchies. The CA hierarchy that you select becomes the server CA mode of the instance. If you're using per-instance CA as the server CA mode for your instance, then the server certificates have an expiration date of 10 years. If you're using shared CA or customer-managed CA as the server CA mode of your instance, then the server certificate has an expiration date of 1 year*. After the expiration date, the server certificate is no longer valid, and clients can no longer establish a secure connection to your instance using that certificate. If a client is configured to verify the CA or verify the hostname in the server certificate, then that client's connections to Cloud SQL instances with expired server certificates will fail. To prevent disruption to client connections, rotate the server certificate before the certificate expires. You're periodically notified that the server certificate is nearing expiration. The notifications are sent the following number of days before the expiration date: 90, 30, 10, 2, and 1.
* For customer-managed CA, the expiration date of your server certificate might be shorter than 1 year if you selected a shorter expiration date for the validity period of your CA.
List and create server certificatesTo view the details of your server certificates in the Google Cloud console, go to the Connections page and click the Security tab.
In the certificates table, you can see the following details:
Before the active certificate expires, you can create a new certificate manually.
ConsoleFor instances that use self-signed server certificates (per-instance CA):
In the Google Cloud console, go to the Cloud SQL Instances page.
The new server CA certificate appears in the Upcoming slot. If you want to rotate to the new server CA certificate immediately, proceed with server CA certificate rotation by updating your clients and completing the rotation.
For instances that use server certificates issued by a shared CA:
In the Google Cloud console, go to the Cloud SQL Instances page.
The new server certificate appears in the Upcoming slot. If you want to use the new server certificate immediately, proceed with server certificate rotation by updating your clients and completing the rotation.
gcloudFor instances that use self-signed server certificates (per-instance CA):
gcloud sql ssl server-ca-certs list \ --instance=INSTANCE_NAME
gcloud sql ssl server-ca-certs create \ --instance=INSTANCE_NAME
gcloud sql ssl server-ca-certs list \ --format="value(cert)" \ --instance=INSTANCE_NAME > \ FILE_PATH/FILE_NAME.pem
server-ca.pem files.For instances that use server certificates issued by a shared CA:
gcloud sql ssl server-certs list \ --instance=INSTANCE_NAME
gcloud sql ssl server-certs create \ --instance=INSTANCE_NAME
gcloud sql ssl server-certs list \ --format="value(ca_cert.cert)" \ --instance=INSTANCE_NAME > \ FILE_PATH/FILE_NAME.pem
server-ca.pem files.To provide server certificate information as an output, use a Terraform data source:
data "google_sql_ca_certs" "ca_certs" {
instance = google_sql_database_instance.default.name
}
locals {
furthest_expiration_time = reverse(sort([for k, v in data.google_sql_ca_certs.ca_certs.certs : v.expiration_time]))[0]
latest_ca_cert = [for v in data.google_sql_ca_certs.ca_certs.certs : v.cert if v.expiration_time == local.furthest_expiration_time]
}
output "db_latest_ca_cert" {
description = "Latest CA certificate used by the primary database server"
value = local.latest_ca_cert
sensitive = true
}
server-ca.pem file, run the following command:
terraform output db_latest_ca_cert > server-ca.pem
Learn more about how SQL Server uses encrypted connections.
Server identity verificationServer identity verification depends on the server certificate authority (CA) hierarchy configuration of your Cloud SQL instance.
For instances that use a per-instance CA, verifying the CA also verifies the server identity since each instance has a unique CA. For instances that use a shared CA, verifying the hostname along with verifying the CA is required for server identity verification since server CAs are shared across instances.
If you have per-instance CA, then you can perform DNS name-based server identity verification only for instances that are configured with Private Service Connect. If you have a shared CA, then you can perform DNS name-based server identity verification for all types of instances, namely Private Service Connect, private service access, and public IP instances.
If you're using a customer-managed CA, then you can verify the CA trust chain and perform DNS name-based server identity verification for any type of instance that uses customer-managed CA for its serverCAmode.
When you select the customer-managed CA option for your instance, you can insert custom DNS names in the SAN field of the server certificate. For more information, see Edit a custom SAN field.
You can view which CA hierarchy is configured for a Cloud SQL instance by viewing instance details. For more information, see View instance information.
Enable server identity verificationIf you select shared CA as the server CA mode of your Cloud SQL instance or if you set up custom DNS names using custom SAN values, then we recommend that you also enable server identity verification.
Instances that use shared CA as the server CA mode contain the instance DNS name in the Subject Alternative Name (SAN) field of the server certificate. You can get this DNS name by using the instance lookup API and using the response as a hostname for server identity verification. You need to set up DNS resolution for the DNS name.
To enable server identity verification for an instance that uses a shared CA, complete the following steps:
Retrieve the DNS name.
To view summary information about a Cloud SQL instance, including the DNS name of the instance, use the gcloud sql instances describe command:
gcloud sql instances describe INSTANCE_NAME \ --project=PROJECT_ID
Make the following replacements:
In the response, look for the dnsNames: field. This field can return multiple DNS names, which have the following formats:
Example:
1a23b4cd5e67.1a2b345c6d27.us-central1.sql.goog. Instance Private services access INSTANCE_UID.PROJECT_DNS_LABEL.REGION_NAME.sql-psa.goog.
Example:
1a23b4cd5e67.1a2b345c6d27.us-central1.sql-psa.goog. InstanceCreate the DNS record in a DNS zone. If you are connecting privately, then create the DNS record in a private DNS zone in the corresponding Virtual Private Cloud (VPC) network.
When you connect to the Cloud SQL for SQL Server instance, configure the DNS name or IP address as the hostname. Then enable server identity verification by specifying the -N flag for sqlcmd or by selecting the Encrypt Connection/Encryption option of SSMS.
Other SQL Server drivers have similar flags or configurations.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4