Update Helm chart GCP mode/guide to use workload identity instead of JSON credentials

[webvictim]

What would you like Teleport to do?

Our GCP Helm guide currently details the configuration of a JSON identity file for the service account which the pod uses. However, the best practice in GCP is now to use workload identity instead of static service account credentials

We should update the Helm chart and GCP deployment guide to recommend and detail the use of workload identity instead of JSON credentials.

What problem does this solve?

Makes use of best practices and make GCP Helm deployments simpler.

If a workaround exists, please include it.

Manually fork/edit the Helm chart and configure workload identity yourself.

[bsgrigorov]

Hey this would be great. We are in the process of trying to use workload identity for teleport deployments in GCP. Can we expect an update on this soon?

[hugoShaka]

I don't think one must fork the chart to use workload identity since v12. If you set chartMode to gcp, unset gcp.credentialSecretName you should be able deploy the chart in gcp mode without passing credentials. You then can add the required SA annotations through auth.annotations.serviceAccount. The rest of the magic happens on google's side: creating the iam SA, role and bindings.

[aardbol]

I don't think one must fork the chart to use workload identity since v12. If you set chartMode to gcp, unset gcp.credentialSecretName you should be able deploy the chart in gcp mode without passing credentials. You then can add the required SA annotations through auth.annotations.serviceAccount. The rest of the magic happens on google's side: creating the iam SA, role and bindings.

This approach indeed works, but doesn't with the Google OIDC connector though.

[hugoShaka]

This approach indeed works, but doesn't with the Google OIDC connector though.

In your experience, what is missing for Google OIDC connector support? What changes did you have to do on the chart and how do you think the chart should support this use-case out of the box?

[gdubicki]

I don't think one must fork the chart to use workload identity since v12. If you set chartMode to gcp, unset gcp.credentialSecretName you should be able deploy the chart in gcp mode without passing credentials. You then can add the required SA annotations through auth.annotations.serviceAccount. The rest of the magic happens on google's side: creating the iam SA, role and bindings.

I am using the teleport-kube-agent chart and I had to set:

annotations:
  serviceAccount:
    iam.gke.io/gcp-service-account: <WI_SA_name>@<GCP_project>.iam.gserviceaccount.com

...plus the appropriate GCP-side config for Workload Identity to work.

[hugoShaka]

I am using the teleport-kube-agent chart and I had to set [...]

Thank you for the feedback. This confirms that there's no technical blocker to do this today, but we would benefit from writing an example in the documentation.

[gdubicki]

The current docs about it at https://goteleport.com/docs/database-access/enroll-google-cloud-databases/postgres-cloudsql/ are kind of funny - they mention that:

WARNING A service account key can be a security risk - we only describe using a key in this guide for simplicity. We do not recommend using service account keys in production. See authentication in the Google Cloud documentation for more information about service account authentication methods.

...but don't describe the alternative. 🙄