Migratie van cloud-IAM en identiteiten naar STACKIT

Hoe elke bronidentiteit wordt gekoppeld

Eén rij per soort identiteit, uit drie runs: een AWS-omgeving van 11 resources en een omgeving van 4 resources voor elk van Azure en Google Cloud.

In de AWS-run werden 11 resources 5 eenheden: het beleid, de koppelingen, het lidmaatschap, het instance profile en de toegangssleutel gaan op in de gebruiker, rol, groep en instance waartoe ze behoren. De concepten voor Azure en Google Cloud schrijven de principal en laten de rechten als open instellingen. Alleen het AWS-concept schreef resources voor roltoewijzing.

Een instancerol wordt een gekoppeld serviceaccount

Links: een EC2-rol en het bijbehorende instance profile zoals de AWS-bron ze declareert. Rechts: drie blokken van het STACKIT-concept in identity.tf, met de commentaarregels boven elk blok weggelaten.

resource "aws_iam_role" "app" {
  name = "reports-app"
  assume_role_policy = jsonencode({
    Version   = "2012-10-17"
    Statement = [{ Effect = "Allow", Action = "sts:AssumeRole", Principal = { Service = "ec2.amazonaws.com" } }]
  })
}

resource "aws_iam_instance_profile" "app" {
  name = "reports-app"
  role = aws_iam_role.app.name
}

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

resource "stackit_authorization_project_role_assignment" "app" {
  for_each    = toset(var.app_project_roles)
  resource_id = var.project_id
  role        = each.value
  subject     = stackit_service_account.app.email
}

resource "stackit_server_service_account_attach" "app" {
  project_id            = var.project_id
  region                = var.region
  server_id             = stackit_server.app.server_id
  service_account_email = stackit_service_account.app.email
}

• De rollen zijn een variabele

  De roltoewijzing leest var.app_project_roles. De beschrijving van de variabele noemt wat het bronbeleid toestaat, s3:GetObject en s3:PutObject, en laat de keuze van de STACKIT-rollen aan u.

• Het recht is ruimer dan het beleid

  Het AWS-beleid noemde één bucket. Een roltoewijzing op projectniveau geldt voor het hele project, en het concept zegt dat: gebruik bindingen per resource waar de STACKIT-dienst die biedt.

• Het instance profile heeft geen object

  Het concept merkt op dat STACKIT geen instance profile kent: de server treedt rechtstreeks op als het gekoppelde serviceaccount, en de trust policy, sessieduur en permissions boundary van de rol worden niet overgenomen.

• Twee valkuilen bij de koppelstap

  Koppelen vergt het recht om als het account op te treden. Het concept legt vast dat een koppeling ongeveer een halve seconde na het aanmaken van het account met 403 werd beantwoord en zo'n zeven seconden later met 201, dus probeer het opnieuw voordat u rechten verdenkt.

Een toegangssleutel wordt een serviceaccountsleutel

Links: de CI-gebruiker met zijn toegangssleutel. Rechts: het serviceaccount, zijn sleutel en de eerste roltoewijzing uit hetzelfde concept; commentaar boven elk blok is weggelaten.

resource "aws_iam_user" "ci" {
  name = "ci-deploy"
}

resource "aws_iam_access_key" "ci" {
  user = aws_iam_user.ci.name
}

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

resource "stackit_service_account_key" "ci" {
  project_id            = var.project_id
  service_account_email = stackit_service_account.ci.email
  ttl_days              = var.ci_key_ttl_days
}

resource "stackit_authorization_project_role_assignment" "ci" {
  count       = length([stackit_service_account.ci.email]) * length(var.ci_project_roles)
  resource_id = var.project_id
  role        = var.ci_project_roles[count.index % length(var.ci_project_roles)]
  subject     = [stackit_service_account.ci.email][floor(count.index / length(var.ci_project_roles))]
}

• De sleutel heeft een levensduur

  ttl_days leest var.ci_key_ttl_days. De beschrijving van de variabele merkt op dat de AWS-toegangssleutels niet verlopen en dat een STACKIT-sleutel zonder ttl_days geldig blijft tot hij wordt verwijderd.

• Het secret reist nooit mee

  De inloggegevens zijn de gevoelige json-uitvoer van de sleutel, door STACKIT aangemaakt. Het AWS-secret wordt nooit gelezen of overgenomen, en de nieuwe sleutel bereikt de aanroepers via een handmatige overdrachtsstap.

• De oude sleutel blijft tot de GO

  De rollback van de overdracht bestaat uit het terugzetten van de aanroepers op de AWS-sleutel, die actief blijft tot de uitfasering van de gebruiker na de GO-beslissing.

• Federatie is een vraag, geen resultaat

  Het bestand over de identiteitsovergang markeert de statische inloggegevens van deze gebruiker als waargenomen en workload identity federation als bewijs vereist. De run beweert nooit dat federatie de sleutel kan vervangen.

Azure: de identiteit verhuist, de roltoewijzing wacht op een persoon

Links: een user-assigned managed identity en de bijbehorende blob-roltoewijzing. Rechts: het enige blok dat het concept ervoor schrijft.

resource "azurerm_user_assigned_identity" "app" {
  name                = "id-reports-app"
  resource_group_name = azurerm_resource_group.app.name
  location            = azurerm_resource_group.app.location
}

resource "azurerm_role_assignment" "app_blob" {
  scope                = azurerm_storage_account.reports.id
  role_definition_name = "Storage Blob Data Contributor"
  principal_id         = azurerm_user_assigned_identity.app.principal_id
}

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

• Drie open instellingen

  Het plan stelt een persoon vragen over de scope van de resourcegroep, de code zonder inloggegevens en de roltoewijzingen. Elke Azure-rol wordt handmatig opnieuw gekoppeld.

• Codewijzigingen in elke consumer

  Code die een managed identity gebruikte, bevat meestal helemaal geen inloggegevens. Op STACKIT zijn serviceaccountgegevens of workload identity nodig, dus elke consumer verandert, niet alleen de infrastructuur.

• Waar het Google Cloud-concept uitkomt

  Het serviceaccount wordt op dezelfde manier gekoppeld en het e-mailadres ervan verandert: verwijzingen naar het oude adres moeten worden bijgewerkt. De binding op projectniveau wordt door een persoon beoordeeld.

De stappen, in volgorde

Algemene praktijk, verbonden met de bestanden van een run.

1. 01

   De identiteitsovergang lezen

   assurance/identity-transition.md noemt elke workload, de statische inloggegevens ervan en of de koppeling aan een server exact is. Het noemt ook wat het niet beoordeelt: privilege delta, break-glass-toegang en menselijke identiteit.

2. 02

   Mensen en workloads scheiden

   Mensen loggen in via de identity provider van de organisatie en groepen worden daar opnieuw aangemaakt. Het concept somt de leden op in een variabele en wijst rollen toe per gebruiker, serviceaccount of client, niet per groep.

3. 03

   De rollen kiezen

   Maak voor elke variabele, zoals app_project_roles, een lijst van de rollen die STACKIT op het project biedt en kies de smalste set die dekt wat het oude beleid toestond.

4. 04

   Accounts aanmaken, daarna koppelen

   Pas de serviceaccounts toe en geef de principal die toepast het recht om als die accounts op te treden. Koppel daarna aan servers en probeer één keer opnieuw als het eerste antwoord 403 is.

5. 05

   Sleutels overdragen of overstappen op federatie

   Geef elke aanroeper van een oude toegangssleutel zijn nieuwe inloggegevens, of zet een gefedereerde identity provider op die de OIDC-issuer van de aanroeper vertrouwt. STACKIT documenteert dat de issuer-URL exact moet overeenkomen met de iss-waarde van de tokens.

6. 06

   De bronidentiteiten als laatste uitfaseren

   Het plan plaatst de uitfasering van gebruikers en rollen na de GO-beslissing, zodat de rollback van een overdracht een terugschakeling naar de oude sleutel blijft.

Beslissingen van de architect

• Rollen per serviceaccount

  De concepten leiden nooit een STACKIT-rol af uit een cloudactie. Een persoon kiest, en de scope van het recht is een project, tenzij een dienst fijnere bindingen biedt.

• Sleutel of federatie

  Een serviceaccountsleutel is een credential, en STACKIT waarschuwt dat een gelekte privésleutel alles blootstelt waartoe het account toegang heeft. Federatie levert kortlevende tokens zonder statische sleutels, maar vereist een OIDC-issuer.

• Projectindeling

  STACKIT kent geen resourcegroep. Waar Azure rollen via een groep liet overerven, bepaalt u hoe de grenzen worden gekoppeld aan projecten, mappen en rollen.

• Tokenflow

  STACKIT documenteert 16 december 2025 als de deprecatiedatum van toegangstokens voor serviceaccounts en biedt een gids voor de overstap van de tokenflow naar de sleutelflow. Bouw nieuwe automatisering op sleutels of federatie.

Vragen van securityteams

Bronnen

• Serviceaccounts, STACKIT-documentatie
• Toegang en identiteit, STACKIT-documentatie
• IAM-rollen, AWS-documentatie
• Managed identities voor Azure-resources, Microsoft Learn
• Overzicht van serviceaccounts, Google Cloud-documentatie