Closed kthhrv closed 1 year ago
This would be much quicker in a videocall :) Check permissions on the automation service account for bootstrap (meaning the SA as a resource), there should be a token creator role assigned to the bootstrap CI/CD service account. On the CI/CD service accounts there should be the workload identity role for the principalset matching your repo.
If you feel like jumping in a call look me up on linkedin and let's troubleshoot this.
@ludoo great thanks I'll do that!
So, let's unravel from the outside:
this should be assigned on your CI/CD SA (the one ending in -1
)
and this on the automation SA (the one ending in -0
)
there's nothing else needed in terms of IAM
both are there
I've requested connection on linkedin, thanks
Thanks for helping @ludoo, nice one spotting that terraform.tfvars had timeoutdigital/fast-00-bootstrap
but the repo was created as timeoutdigital/fast_00_bootstrap
Its appears that stage 0-bootstrap doesn't grant access to the connected service accounts, meaning that the github action doesn't have permission to download the TF output files.
Or maybe I missed a step :)
job failing
service accounts having nothing granted to them
if I manually grant "All identities in the pool" to the account and retry the job it succeeds but removes the perms again so next run fails
here is the relevant part of my 0-bootstrap tfvars
that was copied from the example at https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/fast/stages/0-bootstrap#workload-identity-federation
I believe this issue also impacts the other stages
thanks