Also read - Using a service account across multiple projects

Per Application Service Account

As an application developer, you could generate individual IAM service accounts for each application, and then download and store the keys as a Kubernetes secret that you manually rotate.

Workload Identity GKE

  • Credentials actually issued to the Workload Identity are only valid for a short time, unlike the 10-year lived service account keys, reducing the blast radius in the event of a compromise.
  • Reduce the blast radius - as you would only provide the bare minimum roles to the Service Account that is translated to a workload identity.
  • Google manages the namespace service account credentials for you (saves you the burden of manually rotating these credentials).

How does the Cloud SQL Proxy Auth work?

The Cloud SQL Auth proxy works by having a local client running in the local environment.

Your application communicates with the Cloud SQL Auth proxy with the standard database protocol used by your database.

The Cloud SQL Auth proxy uses a secure tunnel to communicate with its companion process running on the server.

cloudsql proxy authentication
cloud sql proxy authentication

Service  account versus Workload Identity for Cloud SQL Proxy?

It's actually a question of where and how the Proxy service is running. If the proxy is containerized, the workload identity is the preferred solution. If the proxy is not containerized, it will be easier to use a Service Account (the SA details are part of a credentials.json file , which can be easily duplicated on every client machine needing to connect to CloudSQL).

Secrets in Kubernetes

To use a Secret, a Pod needs to reference the Secret. A Secret can be used with a Pod in three ways: