Set-AzCloudTenantSubscription command not working in Gitlab using federated credentials

[jennybeate]

Set-AzCloudTenantSubscription command is not working in Gitlab pipelines using federated credentials. The cloudprovider is set as AzureCloud. Deployments work just fine, when the command is # out.

As gitlab has limitations regarding secrets management, we wish to not use client secrets. This was the same for the previous version of EPAC. Not really sure if this is a question that is best directed to you, but I appreciate pointers as to where to find out more. Due to this, we cannot use the modules, which we would like.

[apybar]

I've assigned this to myself - will review and provide an update by next week.

[apybar]

@jennybeate - Would you be able to provide logs / screenshots and the code snippet you are able to comment out that resolves the issue? I am trying to replicate this on my end however I am not able to.

Also, I will be updating the documentation regarding Federated Credentials as well, this should help in general.

[jennybeate]

This command is in all of the three main deploy scripts and none of them work if I don't have it hashed out.

From the global-settings.jsonc file: "cloud": "AzureCloud"

In gitlab self hosted I cannot set the audience to be api://AzureADTokenExhange, as you probably know. I don't know how that affects how this works, so documentation regarding this will be valuable.

[apybar]

@jennybeate - I was able to successfully set the audience within my .gitlab-ci.yml file. (See code snippet below)

Are you not able to do the same due to restrictions with self-hosted runners?

plan:
  stage: plan
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: api://AzureADTokenExchange
  script:
    - pwsh -c "Connect-AzAccount -Tenant $AZURE_TENANT_ID -ApplicationId $AZURE_CLIENT_ID -FederatedToken $GITLAB_OIDC_TOKEN"

This allows me to login with my federated credentials and then run the "Build-DeploymentPlans" without having errors.

[jennybeate]

I originally tried following documentation when setting up credentials. There is no documentation to be found on what you actually do when you have a self hosted runner, but authentication to Azure started working when I changed it from AzureADTokenExchange to my self hosted runner instance. My organization is considering starting to use the cloud hosted version, so to me it is a relief that it sounds like I will be able to not have a tedious manual update process for this. I'm sure its not too easy for you to test this scenario without self hosted agents..

[apybar]

@jennybeate - I've tested both using the GitLab Provided runners with the following image: "mcr.microsoft.com/powershell:latest" as well as a local self-hosted runner. I still have yet to have an error get thrown during "Set-AzCloudTenantSubscription". Ultimately it will come down to the ability for your runner to reach your Azure Tenant, the way the federated credential is configured within Entra ID, and the method used to authenticate within the GitLab yml.

I would recommend testing with a sample yml file authenticating with the snippet of code I posted above. Since there is little to no documentation for this provided by GitLab, I will update the repo for EPAC to include a starter yml file for GitLab as well as documentation on how to create the federated credential and use it within GitLab. This would probably be easiest to do a side-by-side comparison to what I've tested.

I'll link the update here once the push is complete.

[apybar]

@jennybeate - The starter kit for GitLab leveraging Federated Credentials was pushed last week. Please see here: https://azure.github.io/enterprise-azure-policy-as-code/ci-cd-app-registrations/#alternative-azure-federated-identity-credentials

Further details will be added to the EPAC documentation soon. For now I added documentation regarding Federated Credentials within Entra ID here: https://azure.github.io/enterprise-azure-policy-as-code/ci-cd-app-registrations/#alternative-azure-federated-identity-credentials