[AVM Question/Feedback]: Federated Service Principal credentials

[hundredacres]

Check for previous/existing GitHub issues

• [X] I have checked for previous/existing GitHub issues

Description

Guidance is to not use secrets in Service Principal connections and the contribution docs have steps for setting up this connection with a secret. Are there plans to replace secrets with federated credentials?

[microsoft-github-policy-service[bot]]

[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!

[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[!NOTE] This label was added as per ITA06.

[hundredacres]

You can see a working example here: https://github.com/Azure/bicep-registry-modules/pull/2093

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[!NOTE] This message was posted as per ITA01BCP.

[microsoft-github-policy-service[bot]]

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

• To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

[eriqua]

Several options have been investigated and the resulting suggested approach is the one implemented in PR #2701: auth-type SERVICE_PRINCIPAL + Entity type Environment

The 2 main criteria leading to the above are:

• Feasibility: options not supported by the current CI have been discarded
• Backward compatibility: allow OIDC to be adopted in upstream without causing breaking changes to contributors who already have a fork setup and running

Background:

• Authentication type: the Azure/login GitHub action supports 2 authentication types (auth_type): SERVICE_PRINCIPAL and IDENTITY (managed identity). Authentication via msi has been discarded since only supported by self-hosted runners.
• Azure access token: Azure access token issued by Service Principal auth type is expected to have an expiration of 1 hour (with Managed Identities, it would be 24 hours). The AVM library, includes modules which e2e validation (deployment + deletion) is greater than 1 hour. e.g., sql mi. Those modules, with the default token expiration of 1 hour, would not support OIDC for e2e deployment validation. 2 possible workarounds have been identified:
  • Increase token lifetime. Ref: https://learn.microsoft.com/en-us/entra/identity-platform/configurable-token-lifetimes This option still needs to be tested and discussed since in preview
  • Exempt modules not supporting the default 1h token lifetime, still using azure login via Service Principal Secret (as done today). Use OIDC for all the others. This is the option leveraged by proposed PR #2701
• Azure federated credentials Entity type: For the GitHub Actions deploying Azure resources Federated credential scenario, Azure supports 4 entity types Tested options have been Branch and Environment.
  • Branch: the main drawback of this option is that Azure does not support wildcards (*) for branch names in this context. This means that one federated credential would be required for each branch on which e2e validation is expected to run. Upstream usually runs on main only, although rarely in the past validation was required to run on local branches for testing purposes. However, this option would impact more contributors, usually creating one dev branch for each raised PR. For this reason, this option was discarded with Backward compatibility criteria in mind.
  • Environment: this option is more flexible as supporting all branches with one single federated credential.

Note: the implementation proposed in PR #2701 is backward compatible, meaning after being merged, contributors not yet setting up OIDC in their fork will continue to be supported by azure login via service principal secrets

[eriqua]

Next steps:

• agree on the approach implemented in #2701
• setup GitHub environment and validation secrets in BRM
• implement #2701 changes in a local branch and test
• raise PR from local branch
• document above steps for contributors to adopt OIDC
• investigate on preview option to extend token lifetime. If possible to adopt, remove the workaround for exempted modules
• update onboarding script
• plan to enforce OIDC after an agreed grace period