[FEATURE REQUEST] Modify Service Principal creation to have an access to only one resource group

[toszo]

Is your feature request related to a problem? Please describe. On Azure right now we don't have access to only one resource group using Service Principal creation option.

Describe the solution you'd like We want to have possibility of creation of Service Principal with access only to specific resourge group.

Describe alternatives you've considered None.

Additional context

Currently, when we create a service principal (in contributor role for sub) we need to have an "owner" role in the subscription. It is very problematic when the user doesn't have owner rights.
So the problem has two folds:

1. SP being "contributor" on sub level have to be created by user with "owner" rights.
2. SP is having too wide permission (to all resources within subscription)

---

DoD checklist

• Changelog
  • [ ] updated
  • [ ] not needed
• COMPONENTS.md
  • [ ] updated
  • [ ] not needed
• Schema
  • [ ] updated
  • [ ] not needed
• Backport tasks
  • [ ] created
  • [ ] not needed
• Documentation
  • [ ] added
  • [ ] updated
  • [ ] not needed
• [ ] Feature has automated tests
• [ ] Automated tests passed (QA pipelines)
  • [ ] apply
  • [ ] upgrade
  • [ ] backup/restore
• [ ] Idempotency tested
• [ ] All conversations in PR resolved
• [ ] Solution meets requirements and is done according to design doc
• [ ] Usage compliant with license

[mkyc]

@pprach there was some discussion about requirements for SP, can you comment more about those requirements? @rpudlowski93 can you verify how it applies to previous researches you've been doing?

[rpudlowski93]

Summing up our conversation with @pprach I would recommend to use managed identity which can resolve the metioned problem. Why? Managed identity manages the creation and automatic renewal of a service principal on our behalf and it is highly recommended by azure. There are two kind of managed identity, system-assigned and user-assigned. System-assigned is tied directly to a resource and is automatically removed as soon as the resource is removed. User assigned is created independent of a resource, and can be used between different resources. We have to check, make review and spike the topic, which option could be more appropriate for our usages. The topic is really deep and connecting it with our new approach - modularization, give us many "question marks". Definitely, we should go in the managed approach.

Managed Indentity

[mkyc]

My concern is this sentence from provided link:

Not all Azure services support managed identities, and availability varies by region.

[atsikham]

After some investigation of this topic, reviewing and reading different documents/articles, I don't understand how you are going to do that the same way as now with managed identities. In fact I see 2 options:

1. Use resource group scopes option when create service principal. To do that resource group should be created before applying main Terraform configuration. Example: az ad sp create-for-rbac -n "<app_name>" --role contributor --scopes "/resourceGroups/<resource_group>" Doc: https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az_ad_sp_create_for_rbac

2. Managed identities are used for access from one Azure service to another without configuring any credentials. So we need to create a VM with managed identity (doesn't matter system or user assigned), configure resource group to grant IAM permissions to that identity and then apply Terraform configuration from mentioned virtual machine. For that approach VM and resource group should also be created before applying main terraform configuration. From documentation:

At this point we assume that Managed Service Identity is configured on the resource (e.g. Virtual Machine) being used - and that you are running Terraform on that resource.

Doc: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/guides/managed_service_identity

So I would prefer the first option with a note in modules doc that resource group should be created first and scope is defined. Do we need to make changes anywhere outside modules? I'm asking because initially it's not modules related task.

@toszo @mkyc @rpudlowski93 After your comments I think we can move this task from analysis.

[mkyc]

I would go with first option as well. My opinion is that we should:

• fix documentation
• ensure that current code - which creates RG right now - works ok in this scenario
• create followup task in CLI repo to initialise service principal and resource group (probably in some way connected with this task)

[atsikham]

Created https://github.com/epiphany-platform/cli/issues/16 task.

[toszo]

The thing about this item is: Currently when we create a service principal (in contributor role for sub) we need to have an "owner" role in the subscription. It is very problematic when user doesn't have owner rights. So the problem has two folds:

1. SP being "contributor" on sub level have to be created by user with "owner" rights.
2. SP is having too wide permission (to all resources within subscription)

[atsikham]

The thing about this item is: Currently when we create a service principal (in contributor role for sub) we need to have an "owner" role in the subscription. It is very problematic when user doesn't have owner rights. So the problem has two folds:

1. SP being "contributor" on sub level have to be created by user with "owner" rights.
2. SP is having too wide permission (to all resources within subscription)

So there is an ability to provide a list of resource groups as a scope and necessary roles for that. It's still a question for me if steps that Mateusz listed should be applied only for modules or also in classic Epiphany.

[atsikham]

Discussed with @przemyslavic. Let's keep this issue for Epiphany classic and create other ones for modules - https://github.com/epiphany-platform/m-azure-basic-infrastructure/issues/44 and https://github.com/epiphany-platform/m-azure-kubernetes-service/issues/33. For Epiphany classic we have a few options to implement this task.

1. Create SP with necessary role/scopes before running epicli and update documentation with information about how to do that.
2. Modify automatic SP creation, make it configurable.
3. Both options above.

Context:

• How to use existing SP in Epiphany: create SP, place sp.yml in build/<cluster_name>/terraform, set use_service_principal config parameter, apply configuration. For more information look at sp.yml that is created automatically.
• Where SP is created in Epiphany: https://github.com/epiphany-platform/epiphany/blob/develop/core/src/epicli/cli/engine/providers/azure/APIProxy.py#L46

[seriva]

Not going todo anymore feature requests for Epiphany.