Microsoft Entra ID en Azure RBAC op STACKIT

De migratie in volgorde

1. 01

   1. Inventariseer principals en toewijzingen

   Som elke roltoewijzing op met principal, rol en scope, bijvoorbeeld met az role assignment list. Een Azure-roltoewijzing bestaat uit een security principal, een roldefinitie en een scope; de inventaris krijgt dus die drie kolommen per rij.

2. 02

   2. Behoud Entra ID voor medewerkers, als u dat wilt

   STACKIT ondersteunt het federeren van Entra ID: de documentatie verwijst de meeste Entra-klanten naar de STACKIT Enterprise App en beschrijft een eigen OpenID Connect-federatie voor de overige gevallen. Medewerkers melden zich dan bij STACKIT aan met hun Entra-identiteit, en de tenant blijft de plaats waar instroom en uitstroom worden afgehandeld.

3. 03

   3. Bepaal het scopemodel

   Azure-scopes zijn management group, subscription, resourcegroep en resource. STACKIT-rollen worden gebonden op organisatie-, folder- en projectniveau. Management groups worden gekoppeld aan folders; hoe subscriptions en resourcegroepen worden gekoppeld aan projecten, is een ontwerpbeslissing die de run als openstaand vastlegt.

4. 04

   4. Bouw de rolbindings opnieuw op

   Elke Azure-toewijzing wordt één STACKIT-rolbinding voor een gebruiker, groep of service account. Azure-rollen worden niet op naam overgenomen; elke rol wordt opnieuw gekoppeld aan de rollen die STACKIT voor het product documenteert.

5. 05

   5. Geef workloads service accounts

   Managed identities en de service principals achter automatisering worden service accounts, met een sleutel of met workload identity federation.

6. 06

   6. Pas de code aan die de managed identity gebruikte

   Code die tokens via DefaultAzureCredential verkreeg, heeft STACKIT-inloggegevens of federatie nodig. Dat is een wijziging bij elke afnemer, die de run per identiteit markeert.

7. 07

   7. Test één principal per rol

   Meld u aan als gebruiker met elke rol en als elk service account, en bevestig wat ze wel en niet kunnen voordat de Azure-toewijzingen worden verwijderd.

Objecten van Entra ID en RBAC, en waar ze naartoe gaan

Klassen uit de demorun van 4 november 2026. De middelste kolom komt uit de STACKIT-documentatie die onder de bronnen staat.

Een managed identity wordt een service account

Een kleine omgeving, voor deze pagina geschreven. Links: de user-assigned identity. Rechts: het blok van het concept, zonder de beoordelingsopmerkingen die in het bestand erboven staan.

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"
}

• De naam verandert

  De bronnaam id-report-worker wordt niet overgenomen; het concept noemt het account naar het resourceadres. Hernoem het als clients of runbooks de oude naam zoeken.

• Er komen geen rechten mee

  Een nieuw service account heeft standaard geen toegang tot resources. De rolbindings die de Azure-identiteit toegang tot opslag gaven, zijn de volgende stap en staan niet in het concept.

• Vier instellingen blijven open

  Het rapport noemt de scope van de resourcegroep, code zonder inloggegevens, roltoewijzingen en de locatieresidentie als aan een medewerker overgelaten. Een service account heeft geen eigen regio, dus de residentie wordt bevestigd aan de hand van de regio van het project.

Groepen en de app-registratie, beoordeeld

Uit dezelfde run. Links: twee security groups en een applicatieregistratie. Rechts: de eerste zes regels van de golftabel die de run ervoor schreef.

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,

• Voor groepen bestaat geen resource

  De run stelt vast dat de roltoewijzingsresources van de vastgezette provider elk één subject accepteren, en dat er geen resource is om een principalgroep aan te maken. Om de toegang van een groep na te bouwen is één binding per lid nodig, of u federeert de groep vanuit uw identiteitsprovider.

• De platformdocumentatie noemt groepen

  De pagina over toegangsbeheer van STACKIT toont groepen naast gebruikers en service accounts als subjecten van rolbindings, en de Entra-SCIM-gids koppelt de weergavenaam en leden van groepen. Of een geprovisioned group uw rolbindings kan dragen, is één test waard voordat u eromheen ontwerpt.

• De app-registratie hangt af van het gebruik

  Een workload die Azure-API's aanroept, wordt een service account met een sleutel of gefedereerde identiteit. Een aanmeldapplicatie blijft in Entra ID met nieuwe redirect-URI's. Een pipelineidentiteit verhuist mee met de pipeline. De configuratie toont niet welke van deze situaties geldt, en daarom is het zekerheidsniveau LOW.

Roltoewijzingen: vermeld, niet vertaald

Uit dezelfde run. Links: de drie roltoewijzingen van de demo. Rechts: hoe de run ze vastlegt, met de resourcegroep en de aangepaste rol, in de Terraform-README: als ondersteunende resources die geen enkele eenheid leest.

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 |

• Hun instellingen komen toch ter beoordeling

  Het architectenrapport noemt 16 kritieke instellingen van de vijf ondersteunende resources: de locatie van de resourcegroep, de principal, rol en scope van elke toewijzing, en de scopes, naam en rechten van de aangepaste rol. 15 daarvan zijn gemarkeerd als CLOSED:REVIEW: de run heeft elke instelling verantwoord en draagt die over aan een medewerker, dus die is nog niet beantwoord. De locatie blijft open tot iemand de plaatsing bevestigt. De run stelt de vragen op, niet de antwoorden.

• De landing-zone-lijst telt één binding

  migration/landing-zone-requirements.md telt één stackit_authorization_project_role_assignment als gekoppeld vanuit een broneenheid (de managed identity) maar door geen enkel blok aangemaakt, dus er hoeft nog niets te worden ingeschakeld of op quota te worden geteld. De provider markeert die resource als onderdeel van een opt-in-functie die nog ingrijpend kan veranderen, en de run houdt de identiteitseenheid daarom onder beoordeling van een medewerker.

• Plan de bindings als tabel

  Een spreadsheet met Azure-principal, Azure-rol, scope, STACKIT-subject, STACKIT-rol en niveau is het werkdocument. Beoordelaars tekenen het af voordat iemand een binding toepast.

Medewerkers: federeren en provisioneren

1. 01

   OIDC-federatie

   Voor een eigen OIDC-federatie registreert u een applicatie in Entra ID met de redirect-URL van de STACKIT-identiteitsprovider en voegt u ID-tokenclaims toe voor e-mail, achternaam, voornaam en preferred username. Bij STACKIT opent u een supportticket met het federatietype, de e-maildomeinen en de modus voor het aanmaken van gebruikers, en levert u client-ID, secret, scopes en tenant-ID aan.

2. 02

   Gebruikers wel of niet automatisch aanmaken

   Met automatisch aanmaken aan verschijnen gebruikers bij hun eerste geslaagde aanmelding. Met die optie uit moeten ze vooraf bestaan, bijvoorbeeld via SCIM-provisioning.

3. 03

   SCIM voor gebruikers en groepen

   Provisioning koppelt userName, mail, namen en objectId voor gebruikers, en weergavenaam, leden en objectId voor groepen. STACKIT wijst onverwachte attributen af met HTTP 400, dus koppel alleen wat het verwacht.

4. 04

   E-mail is de sleutel

   Accounts zijn gekoppeld aan e-mailadressen. Het later wijzigen van het federatietype verloopt naadloos zolang de adressen gelijk blijven.

Workloads: service accounts

1. 01

   Twee manieren om te authenticeren

   Een service account kan workload identity federation gebruiken, die een externe OIDC-issuer vertrouwt en kortlevende tokens uitgeeft, of een sleutel. De documentatie noemt de private sleutel zeer gevoelig: houd die buiten de broncode.

2. 02

   Gekoppeld aan servers

   Een service account kan aan een server worden gekoppeld, zodat applicaties tijdelijke tokens van de metadataservice krijgen zonder opgeslagen inloggegevens. Koppelen vereist het recht act-as op het account en een serverrecht.

3. 03

   Geen standaardtoegang

   Service accounts beginnen zonder toegang. Verleen rollen met projectscope via de bindings uit uw tabel.

Beslissingen die de architect neemt

• Entra wel of niet als identiteitsprovider

  Behouden is het kortste pad voor medewerkers; de identiteit elders onderbrengen is een afzonderlijk project.

• Projectindeling

  Wat een subscription en een resourcegroep worden: één project per omgeving is een gebruikelijk begin.

• Groepsstrategie

  Groepen die via SCIM zijn geprovisioned, één binding per persoon, of een combinatie.

• Sleutel of federatie

  Per workload een sleutel met rotatie, of federatie met een externe issuer.

• Residentie van identiteiten

  Bevestig dat de projectregio aan uw eis voldoet; service accounts hebben er geen eigen.

Vragen over Entra ID en RBAC

Bronnen

• Wat is Azure RBAC? (Microsoft Learn)
• Toegangsbeheer (STACKIT Docs)
• Service accounts (STACKIT Docs)
• Een service account aan servers koppelen (STACKIT Docs)
• Federatiegids voor Microsoft Entra ID (STACKIT Docs)
• Identiteitsprovisioning met Entra ID (STACKIT Docs)