feat: User Managed Identity federated within GitHub for CI/CD module

[Krusty93]

List of changes

Adds a module to make easier and reusable the creation of a user managed identity federated with GitHub.

Motivation and context

This change adds a new module that can be used by repositories that need to run GitHub Actions and logging in Azure using a password-less approach. Since potentially every repository might need to run Actions against in Azure, I think that creating a new module is worthing because it can help developers maximising code reusability.

The module allows the consumer to set either ci or cd as identity_role value: depending on which one is used, the module updates subscription IAM permissions with a set of Azure built-in roles.

The consumer can also limit the scope of the identity over a single repository environment or branch or even tags.

Module forces the consumer to use a consistent naming style.

Type of changes

• Add new module
• Update existing module
• Remove existing module

Does this introduce a breaking change?

• Yes
• No

Other information

Run checks

Useful commands to run checks on local machine

bash .utils/terraform_run_all.sh init local
pre-commit run -a

[pasqualedevita]

What is the scope of this module? federation for all github actions or only for infrastructure repos?

[Krusty93]

I'm aware this is a strong assumption, but the goal here is to maintain a naming consistency since the beginning and removing responsibilities on devs - especially in the next days when they will start a migration "losing time for devops things they don't care about" (hope you get the message).

If you agree on this change, I'd also define the resource group in this module instead of referencing it using data for two reasons:

• if we are forcing the name, we already know the name and some work on dev side can be eliminated; of course, they would need to provide location as input variable
• if rg definition was outside of the module, devs needed to "guess" how the module internally forces rg name (ok there's README.md but it is not enough in my opinion)

For devs, providing prefix and env_short is really easy and convenient.

Anyway, let's talk about this. It's just a proposal

cc @diegolagospagopa @pasqualedevita @gunzip

[gunzip]

I agree with the principle of shifting the burden from devs minimizing the setup steps.

[Krusty93]

I had to make a change in the last commit.

Unfortunately, declaring a resource group in a module is a nightmare and considered a bad practice. However, I still want to enforce the rg name by looking for the right name using data resource in the module - if the rg is not found a failure is thrown. This is documented both in code example and readme file.

[gunzip]

consider that infrastructure (hcl) files will go into the code repository when using a monorepo.
does this works with monorepos that contain multiple projects and needs different environments?

@lucacavallaro is this your concern?

[Krusty93]

consider that infrastructure (hcl) files will go into the code repository when using a monorepo. does this works with monorepos that contain multiple projects and needs different environments?

@lucacavallaro is this your concern?

Today I got in touch with @lucacavallaro and with the last commit, it does.

I've added some documentation for naming and resource management in README.md file

[github-actions]

🎉 This PR is included in version 7.19.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀