feat: OIDC auth-type SERVICE_PRINCIPAL using msi + Entity type Environment - branch test

[eriqua]

Description

• Tested backward compatibility.
  CI will continue to use Azure login with service principal + secrets (Azure creds) meanwhile OIDC is set up at repo level and in target subscription.
  

• Created OIDC MSI and granted permissions

• Tested feature on all modules as per pipeline badges below

• Implement OIDC exception list, allowing a subset of modules to temporarily leverage SPN + secret meanwhile their blocker gets investigated and fixed

  • Supporting OIDC
    
    
  • Exempted
    

• Update AVM contribution guidelines

• Testing new modules merged meanwhile

Pipeline Reference

Pipeline
--> (exception uses SPN+secrets)
--> (exception uses SPN+secrets)
--> (exception uses SPN+secrets)
--> unrelated
--> unrelated
--> unrelated
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.utl.types.avm-common-types.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.res.service-networking.traffic-controller.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.res.network.vpn-server-configuration.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.res.fabric.capacity.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.res.document-db.mongo-cluster
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.res.dev-ops-infrastructure.pool.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.virtual-machine-images.![azure-image-builder.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.network.hub-networking.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.dev-ops.cicd-agents-and-runners.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.acr-container-app.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.aks
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.apim-api.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.data.private-analytical-workspace.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.container-app-upsert.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.container-apps-stack.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.insights-dashboard.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.ml-ai-environment.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.ml-hub-dependencies.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.ml-project.yml)
](https://github.com/Azure/bicep-registry-modules/actions/workflows/avm.ptn.azd.monitoring.yml)

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[AlexanderSehr]

I guess we should update every pipeline that runs an Azure Login with the new parameters. I just saw that for example the deployment history cleanup workflow would need the same (but there may be more)

[eriqua]

I guess we should update every pipeline that runs an Azure Login with the new parameters. I just saw that for example the deployment history cleanup workflow would need the same (but there may be more)

@AlexanderSehr the only other workflow to be updated is the cleanup deployments one (addressed already via another PR). All the others using azure login action are already using oidc, but with the publish credentials

[FallenHoot]

This is much needed, because using Service Principals is not best practice and strongly discouraged. https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure#:~:text=Sign%20in%20with%20OpenID%20Connect%20using,principal%20and%20secret%20(Not%20recommended

I tried this fix, but it doesn't work with Pester:

[jtracey93]

Hey @eriqua ,

Firstly, thanks for your work on this PR!

We have made some changes to the AVM CI, detailed below, which means we need you to update your fork to pull in these latest changes and re-run your tests to show they still are passing prior to approving and merging this PR, as we don't and it fails once merged the publishing of your module will fail and will be blocked going forward until the test pass again via additional PRs.

Changes to CI That Have Been Made That You Need To Take Action On

• feat: Add WAF Security PS Rule Config #3745
  • Adds WAF Security PSRule Checks using this custom baseline of rules (/avm/utilities/pipelines/staticValidation/psrule/.ps-rule/cb-waf-security.Rule.yaml)
  • Action Required By You:
    • Ingest/pull-in these changes into your PR branch and re-run your tests to ensure they pass
      • If any issues with the rules and you think it should apply, please ping/reach out to the core team

Any questions reach out to the AVM Core Team by tagging us in your PR here or internally via Teams

Thanks

Jack (AVM Core Team)