An example using Cloud SQL that shows how the root password can be securely generated and used.

[sf-vorlov]

Is your feature request related to a problem? Please describe.
Hi Mathieu. I am trying to expand your examples to provision (and to use) a Cloud SQL instance. I am struggling to understand how and where can I create a root password - in secure manner.
As I'd be creating an SQL Instance as a part of the tenant project repo-sync I'd need to provide a password either explicitly (bad idea) or as a reference to a secret (better idea). If it is a secret, then it need to exist in the config controller cluster. However then I'd need to pass the password to the tenant GCP cluster, so that it can be consumed by the application.

So I'm thinking deploy the secret through the helm, using the randAlphaNum template function. Use that to provision the database instance and write it to a secret manager to the tenant project with the SecretManagerSecretVersion.
Then in the tenant GKE cluster I can read it back one way or another (i.e. with the external secrets controller)

Describe the solution you'd like
A Cloud SQL is provisioned. A root password is not committed to any of the Git repos. The password is used by a sample application.

Describe alternatives you've considered

Additional context

[mathieu-benoit]

Hi @sf-vorlov, thanks for reaching out.

So, my plan is to add in the Bank of Anthos section the Cloud SQL setup by adapting this here: https://github.com/GoogleCloudPlatform/bank-of-anthos/tree/main/extras/cloudsql.

With that said, related to your question, I was on the same page as you regarding to the secrets management.

In a GitOps way to manage secrets, there are options (I recently attended this very insightful session). I was thinking about using one of those 2:

• Google Secret Manager Provider for Secret Store CSI Driver
• External Secrets Operator

But still remain the question about the secret values stored in the Infra Git repo... so here I was wondering if we could leverage the Sealed Secret project. That's something I have never used before, need to find time to try this out and see how it fits.

With all of that said, I think what I would prefer to implement with Cloud SQL is the secret-less approach by leveraging this IAM database authentication feature. Have you seen this? What do you think?

[sf-vorlov]

Hi @mathieu-benoit!

The video provides a nice summary of the options. Out of all, discussed there I have used SOPS, ArgoCD level expansion (not the Vault plugin though, but the helmfile fetchSecretValue), the Vault agent and the external secrets operator.

I am also thinking of the CSI Driver or the External Secrets approach. The problem is how to generate (and to rotate) the secret in the first place. I was hoping to use https://github.com/mittwald/kubernetes-secret-generator, however, my understanding, no 3rd party components can be installed on the GCP managed config controller. Hence the randAlphaNum Helm function approach. It breaks the idea of using the rendered manifests, so I need figure out how to mix and match them with the Helm chart - without too much kustomization code.

I've looked at the IAM database authentication. The problem with that approach is "When an IAM user is added to a database instance, that new user is granted no privileges on any databases, by default", so, once again, we'd need a root user/password for that.
I'd will still consider the IAM database authentication - in addition to the CSI Driver or External Secrets, as it would solve a problem of the lag between the password rotated and it is available to the application - since the root credentials would only need to play role when we run the grant command - perhaps as an out-of-band k8s job.