[DEVEX-179] Add a TF module to make mono-repository setup easier

[Krusty93]

List of changes

This PR adds a new Terraform module with to make the mono-repository setup a little more simpler.

This module includes:

• an Azure resource group for the entire mono-repository
• managed identities federated with GitHub for:
  • "infra" pipelines
  • "app" pipelines
  • "opex" pipelines
• RBAC roles for:
  • AD teams
    • team admins
    • team developers
    • (eventually) team external members
  • Managed identities mentioned above

If a team needs more resource groups, they can be defined into the resources configuration. However, all roles on that scope must be defined in there as well.

What is missing:

GitHub repository and its configuration is not in this module. This because is still difficult to import the repository inside the Terraform state file at the stage of the first apply.

Few alternative approaches:

• do it through Compass (if possible)
• leaving the manual approach (= Cloud Eng. in charge of do it as this module requires subscription high-privileges)

Constraints:

Versions constraints are intentionally high.

Azurerm pretends >= v4
Terraform versions should be >= 1.9.x

Requirements:

Before using this module, team must ensure to have at least two AD groups (admins, devs and eventually externals) with different subscription roles

Motivation and context

Two main reasons brought the creation of this module:

• devs can't manage locks on their own resources and this is a bottleneck. With this module, team admins will be able to do it
• currently, each dev can add, modify and destroy resources of other teams, but the only reason why a member of a team would do it is a mistake. In fact, this is not a need but only a consequence of the current management. Adopting patterns induced by this module, permissions will shifts to a read-only approach

Moreover, it avoids manual setup for "apps" and "opex" managed identities as the actual module uses "infra" roles as defaults.

Why now?

Patterns and needs are clearer now, then making assumptions is easier

Type of changes

• Add new resources
• Update configuration to existing resources
• Remove existing resources

Does this introduce a change to production resources with possible user impact?

• Yes, users may be impacted applying this change
• No

Other information

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1d0fd83

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[gunzip]

why false?

[Krusty93]

I don't see any value in having the branch up to date before merging as CI pipelines run over the merge commit

[gunzip]

can you elaborate a little bit more?

[Krusty93]

As we're talking about monorepository (aka a single, potentially large repository), there is an high possibility that PR's branch is not up to date with main as other people are working on the same code base. I don't see this as an issue because the delta does not affect the validity of CI checks nor "manual" review as changes are on different paths. On the other hand, if changes are on the same files it is likely to have conflicts and PR cannot be merged

[gunzip]

let's see what @pagopa/engineering-team-devex thinks about this

[gunzip]

we should add a validation to set required tags (team name / domain)

[Krusty93]

Can you explain it a little more?

[gunzip]

I mean: tags shouldn't ever be an empty map, but contains at least the team / domain.

[Krusty93]

Which tags? I don't follow you :)

[gunzip]

the usual ones Owner , Source, ... aren't required?

[gunzip]

minor improvements