Missing roles/iam.workloadIdentityUser for cicd configuration in 0-org-setup ?

[vvision]

Hello,

While deploying a new landing zone, using the new stages, I encountered an error with workload identity federation.
My cicd configuration is targeting Gitlab Saas. I solved my issue patching the 0-org-setup locally, and opened a PR describing my problem: #3389.

Following with the answer from @ludoo, I tried to understand the way permissions are set to the right principalSet, but it seems to me as if something is missing in the stage.

If my understanding is correct, permissions would be set using principal_branch and/or principal_repo, that are defined in wif-definitions.tf. It should also used data defined in cicd.yaml, under workflows > <id> > repository, name and branch.

What puzzle me, is that looking for the string principalSet in the 0-org-setup only returns results from the wif-definitions.tf file. So it seems to me as if it's unused and something is missing.

Looking at stage 0-bootstrap, in file cicd.tf from v43, I see some lines related to roles/iam.workloadIdentityUser, that use principal_branch, principal_repo, repository.name and repository.branch:

cloud-foundation-fabric/fast/stages/0-bootstrap/cicd.tf

Lines 79 to 94 in b245abf

	iam = {
	"roles/iam.workloadIdentityUser" = [
	each.value.repository.branch == null
	? format(
	local.workload_identity_providers_defs[each.value.repository.type].principal_repo,
	google_iam_workload_identity_pool.default[0].name,
	each.value.repository.name
	)
	: format(
	local.workload_identity_providers_defs[each.value.repository.type].principal_branch,
	google_iam_workload_identity_pool.default[0].name,
	each.value.repository.name,
	each.value.repository.branch
	)
	]
	}

I do not see something similar in 0-org-setup starting with v44.

Am I right to think that the configuration of roles/iam.workloadIdentityUser has been lost going from v43 to v44 and from 0-bootstrap to 0-org-setup, or have I been missing something while reading the code ?

[ludoo]

Yes, that role seems to have indeed been lost. Let me try to bring it back, and thanks for opening this.

[ludoo]

Did a quick check, and will spend a bit more time tomorrow to make sure of the approach, but my preference would be for injecting principal/principalsets in the context's iam_principals namespace, so that the grants can be explicit in the YAML files where the CI/CD service accounts are created.

Will send a patch tomorrow, and run a few extra tests on this implementation of CI/CD.

[ludoo]

#3454 should fix this, it still needs some cleanup and required a few rounds of changes to the service account module

[ludoo]

PR above has now been merged to fast-dev. If you give it a try, mind letting us know if it solves your issues? And thanks again for reporting this.