GCP secure connectivity for GKE & CloudSQL

Securely consume CloudSQL instances from app deployments in a GKE cluster using private IP secure connectivity with new Crossplane resources in the GCP Stack including: Networks, Subnetworks, GlobalAddresses, and Private Service Connections -- all from kubectl!

Continuing our series on cloud networking & security we’ll explore new support for private IP secure connectivity for CloudSQL instances (MySQL, PostgreSQL) provisioned from kubectl with Crossplane.

GCP supports multiple options for connecting GKE to CloudSQL. Crossplane v0.2 supported the public IP method for CloudSQL instances, but it wasn’t very secure unless you were using the CloudSQL Proxy.

Crossplane v0.3 adds support for the private IP method, that internally uses VPC peering to ensure traffic isn’t passed over the public Internet. Whitelisting public CIDRs is also now supported.

Manual steps

Adding private IP connectivity for GKE and CloudSQL requires the following:

1) GKE Cluster Setup

  1. Private Network for the GKE cluster.
  2. Subnetwork with IP ranges for the GKE cluster:
  1. VPC-native GKE cluster with Alias IPs enabled, so Pod IP addresses are natively routable within the GCP network (including via VPC Network Peering) and can directly access managed services, like CloudSQL, without using a NAT gateway.

2) Configure Private Services Access

  1. Internal Global Address for VPC peering to define the IP range that will used to allocate private addresses for managed services, like CloudSQL, offered by a service producer.
  2. Private Service Connection to a service producer that offers one or more managed services like CloudSQL. Behind the scenes, it creates a VPC peering connection to the network where those service instances actually live. If a single service producer offers multiple services, you only need one private connection for all of the producer's services. See configuring private service access for details.

3) Provision managed services with private IPs on the cluster's network
Managed service instances (CloudSQL, CloudMemorystore) can then be provisioned and specify the private network they should be made available on, and will be allocated a private IP from the associated GlobalAddress and be reachable from the pods in the cluster.

Streamline GKE & CloudSQL provisioning with kubectl

Luckily all of the steps above can be done using kubectl by following the GCP Stack Setup Guide. It uses a standalone Crossplane control cluster running on your laptop or in the cloud to create a secure networking environment in GCP and dynamically provision a GKE cluster with CloudSQL provisioning enabled.

Note the following additions:

  • The GKEClusterClass has a new enableIPAlias field - so Pod IP addresses are natively routable within the GCP network.
  • The CloudSqlInstanceClass has a new privateNetwork field - the VPC network to which CloudSQL instances will be made available with a private IP allocated from the previously configured Global Address and routed via the Private Service Connection.

Add CloudSQL provisioning to existing GKE clusters

If you already have an existing VPC-native GKE cluster with Alias IPs enabled then you can install an embedded Crossplane instance directly onto the target GKE cluster along with the GCP Stack and then follow the GCP Services Guide to enable managed service provisioning.

This adds managed service CRDs to the Kubernetes API including CloudSQL for MySQL and PostgreSQL. You can continue deploying to Kubernetes with the core resources you use today (deployments, pods, services, ingress) and augment that with additional Kubernetes objects (mysql.yaml, postgres.yaml) to provision managed services using kubectl.

Provision securely connected DB instances

Once managed service provisioning is enabled you can dynamically provision CloudSQL instances in your app project namespaces using PostgreSQL and MySQL claims, but now with secure connectivity!

Beyond v0.3

If you’d like to use the CloudSQL proxy method please let us know, it’s an active topic of conversation! We’re also looking at adding secure connectivity policies that let you pick the strategy you want (public IP, private IP, or CloudSQL proxy) and it would provision the primitives automatically.

Learn more

To learn more about key design considerations, how secure connectivity fits into Crossplane's layered architecture, and a detailed example to make it real, checkout:

Get involved!

There are many different ways to get involved in the Crossplane project, both from the user side and the developer side. Please join us in helping the project continue to grow on its way beyond the v0.3 milestone as we move from alpha to beta over the coming months!

Join the open cloud movement to help level the playing field for everyone!

Keep up with Upbound

* indicates required