Using a Google service account keyfile in a Kubernetes serviceaccount as a testing environment replacement for GKE workload identity

4/29/2021

I have a GKE app that uses kubernetes serviceaccounts linked to google service accounts for api authorizations in-app.

Up until now, to test these locally, I had two versions of my images- one with and one without a test-keyfile.json copied into them for authorization. (The production images used the serviceaccount for authorization, the test environment would ignore the serviceaccounts and instead look for a keyfile which gets copied in during the image build.)

I was wondering if there was a way to merge the images into one, and have both prod/test use the Kubernetes serviceaccount for authorization. On production, use GKE's workload identity, and in testing, use a keyfile(s) linked with or injected into a Kubernetes serviceaccount.

Is such a thing possible? Is there a better method for emulating GKE workload identity on a local test environment?

-- Ral
google-kubernetes-engine
kubernetes

1 Answer

5/27/2021

I do not know a way of emulating workload identity on a non-Google Kubernetes cluster, but you could change your app to read the auth credentials from a volume/file or the metadata server, depending on the environment setting. See this article (and particularly the code linked there) for an example of how to authenticate using local credentials or Google SA depending on environmental variables.The article also shows how to use Pod overlays to keep the prod vs dev changes separate from the bulk of the configuration.

-- Goli Nikitha
Source: StackOverflow