The code language I'm using is Terraform (Hashicorp Configuration Language or HCL) as the 'infrastructure as code' to automate the process of GCP creating everything for the server stack, and Helm charts for the M2 application. I've gotten as far as Terraform will create the GKE cluster, node pool, and Cloud SQL database, including the VPC network, virtual peering, and it's all secured with service accounts, etc. The database is on a private IP address with SSL applied, and I can confirm it is linked properly as far as on the same private VPC network as the GKE cluster (which has a public endpoint and Ingress setup with an external load balancer). The next step is to enable GKE to work on the Cloud SQL instance.
In the Google Guides section, they describe various methods to connect GKE and Cloud SQL, here at this link:
https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine
Cloud Auth Proxy is mentioned, although in my research, I heard going with that option it was a more complex route -- and in the Google Guide, it says:
"If you are using Google Kubernetes Engine, the preferred method is to use GKE's Workload Identity feature."
Which seems to indicate that using GKE's Workload Identity, to link GKE to Cloud SQL, is a separate option than via Cloud Auth Proxy, no?
For example, in my Terraform file, in creating the primary cluster, I have:
// GKE: GOOGLE KUBERNETES ENGINE
// Creates the primary cluster
resource "google_container_cluster" "primary" {
name = var.cluster
project = var.project_id
location = var.zones
... ... ...
// This is required to have workloads and to enable gke metadata on the node pods.
workload_identity_config {
workload_pool = "${var.project_id}.svc.id.goog"
}
... ... ...
I'm using YAML files for my Magento 2 application, but I'm running that as a separate deployment from the Terraform code which manages the GCP server stack, which deploys the app only once the Terraform has configured the server stack on GCP. I currently do not have any YAML files configured manually with the Terraform code base; however, if there is a way to add a YAML to a Terraform chart, then I would be eager to learn more about that process.
I've added the Workload Identity to the GKE cluster, but so far my testing hasn't resulted in GKE successfully linking to the Cloud SQL database.
However, there is a new 'simplified operator available in YAML file to connect GKE and Cloud SQL available here:
Per the above link, what is the difference between Cloud SQL Proxy Operator and Cloud Auth Proxy?
Does Cloud SQL Proxy Operator work along with Google's Workload Identity (per the link below) -- to connect GKE and Cloud SQL -- or is Workload Identity not necessary? My next test for the Workload Identity will be to bind the GCP service account on the database to the Kubernetes service account, but I don't know if that will be sufficient to enable GKE to work directly on the Cloud SQL database -- or whether Cloud SQL Proxy Operator or Cloud Auth Proxy would also be helpful to add that as well.
Update: there is an alternative option, instead of using Cloud Auth Proxy, or Cloud Auth Proxy Operator, to connect GKE to Cloud SQL, and that is -- Google enabled private ip address connection, if the GKE cluster was created in VPC Native mode.
Since I'm using Terraform code for the stack, then Terraform doesn't create GKE clusters in VPC-Native mode by default, so a few extra lines of code are added to create the GKE cluster via Terraform in VPC-Native mode.
Once that step is completed, then the other key component is to create the Cloud SQL instance within the Virtual Private Network at the same time via Terraform as the GKE cluster (in VPC-Native mode). The sequence here is also key to ensure GKE and Cloud SQL are created within the same network.
There are other important, by relatively minor steps, to enabling this overall connection for GKE and Cloud SQL, that I've discovered including:
Having a kube identity service account created by Terraform, with Workload Identity applied, and appropriate IAM roles, which allows authentication between GKE and Cloud SQL
create the Virtual Private Network with two (or more) subnetworks -- this is basically what allows the GKE cluster to connect to Cloud SQL via the private ip address, rather than Cloud Auth Proxy.
It's referenced here at this article, as working in general, but the actual Terraform code is detailed further on the Terraform site docs:
described in the section "Using databases in Kubernetes"
If the entire Virtual Private Network is set to private access only, with no public internet traffic, then the private ip endpoint address can be set just in the main subnetwork, which connects with the Cloud SQL service network (ie. it's auto-generated subnetwork).
However, if the network may have any public web traffic, then one alternative option would be to setup two different subnetworks, as illustrated in this 5-part article that describes how to code in Terraform to create a Virtual Private Network with the two subnetworks, one for internet traffic with public access and one that is firewalled as a private-only subnetwork:
https://dev.to/stack-labs/configuring-an-isolated-network-in-google-cloud-5cib
Going this route may also require either Private Services Connect (PSC) or Virtual Peer Networking (which Google also calls Private Services Access, or PSA). PSC and PSA sound very similar but Google Cloud treats how they operate differently, and each has unique Terraform code. Since my Magento 2 project is using Google Cloud NetApp for file volume storage, the GCP NetApp requires its own virtual peering network (ie. PSA). Since it's reportedly better to limit the number of virtual peering networks, then I setup the GKE-to-SQL directly via PSC, not PSA, based upon this tutorial:
The above tutorial also mentions its possible to add Cloud Auth Proxy on top of Private Services Connect to add an extra layer of security, as an additional option.
Since creating a Virtual Private Network was the original basis to manage the Magento 2 site operation from the start, then configuring it in a way that enables the private ip address connection for GKE to Cloud SQL without the necessity of Cloud Auth Proxy seems preferable for my sitebuilding project.
Overall, while I understand Cloud Auth Proxy and Cloud Auth Proxy Operator have their use cases where they may come in handy, and I certainly appreciate the efforts and feedback of the community in this regard -- this is additional feedback for anyone else who may be considering their options for how to best setup a connection between GKE and Cloud SQL.