Microsoft Entra ID and Azure RBAC on STACKIT

The migration in order

1. 01

   1. Inventory principals and assignments

   List every role assignment with its principal, role and scope, for example with az role assignment list. An Azure role assignment is a security principal, a role definition and a scope; the inventory has those three columns per row.

2. 02

   2. Keep Entra ID for people, if you want to

   STACKIT supports federating Entra ID: its documentation points most Entra customers to the STACKIT Enterprise App and describes a custom OpenID Connect federation for the other cases. People then sign in to STACKIT with their Entra identity, and the tenant stays the place where joiners and leavers are handled.

3. 03

   3. Decide the scope model

   Azure scopes are management group, subscription, resource group and resource. STACKIT roles are bound at organization, folder and project level. Management groups map to folders; how subscriptions and resource groups map to projects is a design decision the run records as open.

4. 04

   4. Rebuild role bindings

   Each Azure assignment becomes one STACKIT role binding for a user, group or service account. Azure roles do not carry over by name; each is re-mapped to the roles STACKIT documents for the product.

5. 05

   5. Give workloads service accounts

   Managed identities and the service principals behind automation become service accounts, with a key or with workload identity federation.

6. 06

   6. Change the code that used the managed identity

   Code that obtained tokens through DefaultAzureCredential needs STACKIT credentials or federation. This is a change in every consumer, which the run flags per identity.

7. 07

   7. Test one principal per role

   Sign in as a user with each role and as each service account, and confirm what they can and cannot do before the Azure assignments are removed.

Entra ID and RBAC objects, and where they go

Classes from the demo run of 4 November 2026. The middle column comes from the STACKIT documentation named under sources.

A managed identity becomes a service account

A small estate written for this page. Left: the user-assigned identity. Right: the block of the draft, without the review comments that sit above it in the file.

resource "azurerm_user_assigned_identity" "worker" {
  name                = "id-report-worker"
  location            = azurerm_resource_group.platform.location
  resource_group_name = azurerm_resource_group.platform.name
}

resource "stackit_service_account" "worker" {
  project_id = var.project_id
  name       = "worker"
}

• The name changes

  The source name id-report-worker is not carried; the draft names the account after the resource address. Rename it if clients or runbooks look for the old name.

• No permissions come with it

  A new service account has no access to resources by default. The role bindings that gave the Azure identity access to storage are the next step and are not in the draft.

• Four settings stay open

  The report lists resource-group scope, credential-less code, role assignments and location residency as left to a person. A service account has no region of its own, so residency is confirmed against the region of the project.

Groups and the app registration, assessed

From the same run. Left: two security groups and an application registration. Right: the first six lines of the wave table the run wrote for them.

resource "azuread_group" "platform_admins" {
  display_name     = "platform-admins"
  security_enabled = true
}

resource "azuread_group" "report_readers" {
  display_name     = "report-readers"
  security_enabled = true
}

resource "azuread_application" "portal" {
  display_name = "customer-portal"
}

wave,wave_state,unit,type,module_call,presence,class,confidence,application,application_status,proposed_group
1,MEMBER,azuread_application.portal,azuread_application,,KNOWN_PRESENT,MANUAL_REVIEW,LOW,,UNASSIGNED,
1,MEMBER,azuread_group.platform_admins,azuread_group,,KNOWN_PRESENT,REDESIGN,MEDIUM,,UNASSIGNED,
1,MEMBER,azuread_group.report_readers,azuread_group,,KNOWN_PRESENT,REDESIGN,MEDIUM,,UNASSIGNED,
1,MEMBER,azurerm_storage_account.reports,azurerm_storage_account,,KNOWN_PRESENT,REPLATFORM,MEDIUM,,UNASSIGNED,
1,MEMBER,azurerm_user_assigned_identity.worker,azurerm_user_assigned_identity,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,,UNASSIGNED,

• Groups have no resource to become

  The run finds that the role assignment resources of the pinned provider take one subject each, and that it has no resource to create a principal group. Reproducing a group's access means one binding per member, or federating the group from your identity provider.

• The platform documentation names groups

  The STACKIT access-control page lists groups next to users and service accounts as subjects of role bindings, and the Entra SCIM guide maps group display name and members. Whether a provisioned group can carry your role bindings is worth one test before you design around it.

• The app registration depends on its use

  A workload calling Azure APIs becomes a service account with a key or federated identity. A sign-in application stays in Entra ID with new redirect URIs. A pipeline identity moves with the pipeline. The configuration does not show which of these applies, which is why the confidence is LOW.

Role assignments: listed, not translated

From the same run. Left: the three role assignments of the demo. Right: how the run records them, with the resource group and the custom role, in the Terraform README: as support resources that no unit reads.

resource "azurerm_role_assignment" "admins_owner" {
  scope                = azurerm_resource_group.platform.id
  role_definition_name = "Contributor"
  principal_id         = azuread_group.platform_admins.object_id
}

resource "azurerm_role_assignment" "readers_blob" {
  scope                = azurerm_storage_account.reports.id
  role_definition_name = "Storage Blob Data Reader"
  principal_id         = azuread_group.report_readers.object_id
}

resource "azurerm_role_assignment" "worker_operator" {
  scope              = azurerm_resource_group.platform.id
  role_definition_id = azurerm_role_definition.report_operator.role_definition_resource_id
  principal_id       = azurerm_user_assigned_identity.worker.principal_id
}

| Source | Kind | Read by |
|---|---|---|
| `azurerm_resource_group.platform` | support resource | `azurerm_storage_account.reports`, `azurerm_user_assigned_identity.worker` |
| `azurerm_role_assignment.admins_owner` | support resource | no unit of the source reads it |
| `azurerm_role_assignment.readers_blob` | support resource | no unit of the source reads it |
| `azurerm_role_assignment.worker_operator` | support resource | no unit of the source reads it |
| `azurerm_role_definition.report_operator` | support resource | no unit of the source reads it |

• Their settings still reach review

  The architect report lists 16 critical settings of the five support resources: principal, role and scope of each assignment, and the scopes, name and permissions of the custom role, each closed as a review item. The run draws up the questions, not the answers.

• The landing-zone list counts one binding

  migration/landing-zone-requirements.md counts one stackit_authorization_project_role_assignment as mapped from a source unit (the managed identity) but created by no block, so nothing has to be enabled or counted against quota for it yet. The provider marks that resource as part of an opt-in feature that may still change significantly, and the run therefore keeps the identity unit under a person's review.

• Plan the bindings as a table

  A spreadsheet of Azure principal, Azure role, scope, STACKIT subject, STACKIT role, level is the working artefact. Reviewers sign it before anyone applies a binding.

People: federate and provision

1. 01

   OIDC federation

   For a custom OIDC federation you register an application in Entra ID with the redirect URL of the STACKIT identity provider and add ID-token claims for email, family name, given name and preferred username. At STACKIT you open a support ticket with the federation type, the email domains and the user creation mode, and supply client ID, secret, scopes and tenant ID.

2. 02

   Create users automatically, or not

   With auto creation on, users appear at their first successful sign-in. With it off, they must exist beforehand, for example through SCIM provisioning.

3. 03

   SCIM for users and groups

   Provisioning maps userName, mail, names and objectId for users, and display name, members and objectId for groups. STACKIT rejects unexpected attributes with HTTP 400, so map only what it expects.

4. 04

   Email is the key

   Accounts are tied to email addresses. Changing the federation type later is seamless as long as the addresses stay the same.

Workloads: service accounts

1. 01

   Two ways to authenticate

   A service account can use workload identity federation, which trusts an external OIDC issuer and issues short-lived tokens, or a key. The documentation calls the private key highly sensitive: keep it out of source code.

2. 02

   Attached to servers

   A service account can be attached to a server so that applications get temporary tokens from the metadata service without a stored credential. Attaching needs the act-as permission on the account and a server permission.

3. 03

   No default access

   Service accounts start with no access. Grant project-scoped roles with the bindings from your table.

Decisions the architect owns

• Entra as identity provider or not

  Keeping it is the shortest path for people; moving identity away is a separate project.

• Project layout

  What a subscription and a resource group become: one project per environment is a usual start.

• Group strategy

  SCIM-provisioned groups, one binding per person, or a mix.

• Key or federation

  For each workload, a key with rotation or federation with an external issuer.

• Residency of identities

  Confirm that the project region meets your requirement; service accounts have none of their own.

Questions about Entra ID and RBAC

Sources

• What is Azure RBAC? (Microsoft Learn)
• Access control (STACKIT docs)
• Service accounts (STACKIT docs)
• Attaching a service account to servers (STACKIT docs)
• Microsoft Entra ID federation guide (STACKIT docs)
• Identity provisioning with Entra ID (STACKIT docs)