AWX, Workload Identity Federation & GCP

,

I’m looking for a solution to enable AWX to authenticate against GCP keylessly. I’ve seen implementations of such using GitHub Actions and Jenkins which use Workload Identity Federation. To the best of my understanding, a trust relationship is setup between a local entity that is able to impersonate a GCP service account and issue tokens on behalf of it that are valid in GCP. I don’t think such a feature exists in AWX. If it were, I suppose it would be based around a new credential type which would inject a GCP token into a job.

I could sort of do this using a GCP secrets engine in Hashicorp Vault to generate the token and a Hashicorp Vault Secret Lookup to read the generated token from Vault. However the GCP secret in Hashicorp Vault requires a GCP key and the Hashicorp Vault Secret Lookup in AWX requires a client ID and client secret. All of which is potentially vulnerable to exfiltration and needs to be regularly rotated.

2 Likes

Interesting. This has led me to begin reading about “Workload Identity Federation”. Do you agree that Service Account Key JSON" is not what you are looking for?

I’m going to try and read more about #1 and #2

edit:
Autenticar cargas de trabalho nas APIs do Google Cloud usando contas de serviço  |  Compute Engine Documentation If you are staying in GCP, I think this is all you need.

It’s not what I’m looking for. The SA key is a long-lived key and providing that to AWX is what I want to avoid.

BTW The link you provide is for authentication to GCP using Github Actions where you can either configure a SA key or set up Workload Identity Federation. I have done the latter, with Github Actions. I’m looking for the same possibility with AWX.

If you run AWX inside GKE you can use WIF with the k8s ServiceAccount runnig the AWX pod.

This is very easy to setup with container groups. You just have to set ‘automountServiceAccountToken’ in the pod spec to true.

And give the k8s ServiceAccount the needed permission in GCP directly or allow it to impersonate as a GCP service account.

We use this setup to generate GCP service account access tokens within some custom action plugins.
That access tokens can be passed to modules run on remote hosts.

1 Like

Thanks but that’s not an option for me.