Migratie van GCP IAM en service accounts naar STACKIT

Een service account, de sleutel en de rol, beoordeeld

Een kleine identiteitsomgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld (acht resources). Links: het CI-deployeraccount, de sleutel en de projectbinding. Rechts: het enige blok van die groep dat de engine als Terraform schrijft; de reviewcommentaren erboven in het bestand zijn hier weggelaten. De invoerblokken staan in main.tf niet naast elkaar, dus elk heeft een eigen paneel, letterlijk.

resource "google_service_account" "deployer" {
  account_id   = "ci-deployer"
  display_name = "CI deployer"
}

resource "google_service_account_key" "deployer" {
  service_account_id = google_service_account.deployer.name
}

resource "google_project_iam_member" "deployer_editor" {
  project = "shop-platform-prod"
  role    = "roles/editor"
  member  = "serviceAccount:${google_service_account.deployer.email}"
}

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

• De naam blijft, het adres niet

  De accountnaam komt uit account_id. Het e-mailadres verandert, omdat STACKIT het genereert, dus elke verwijzing naar het oude adres iam.gserviceaccount.com moet worden bijgewerkt. Het adresformaat van Google is naam, project-id en iam.gserviceaccount.com; zoek ernaar in applicatieconfiguratie, bucketbeleid en CI-variabelen.

• De weergavenaam heeft geen plek

  stackit_service_account accepteert alleen een naam en een project-id, dus de weergavenaam staat in de lijst met niet overgenomen eigenschappen. Bewaar de omschrijving in uw eigen inventaris.

• Acht resources, twee eenheden

  Alleen de twee service accounts zijn eenheden. De sleutel hangt als facet aan de deployer-eenheid. De drie projectbindingen, de custom role en de workload identity-binding worden vastgelegd als ondersteunende resources die geen enkele eenheid leest, en het concept schrijft er niets voor.

Wat de run aan een persoon overlaat

Uit dezelfde run: een fragment van de deployer-eenheid in assessment.json, met de waarden precies zoals de run ze schreef. Twee kritieke instellingen blijven open: de rolbindingen en de langlevende sleutel.

{
  "id": "google_service_account.deployer",
  "facets": [
    "google_service_account_key.deployer"
  ],
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "resources": [
        "stackit_service_account",
        "stackit_authorization_project_role_assignment"
      ]
    },
    "findings": [
      {
        "severity": "info",
        "message": "Long-lived JSON keys are issued; they become STACKIT service account keys — or disappear where workload identity replaces them."
      }
    ],
    "semantics": {
      "critical_open": [
        "long-lived-keys",
        "role-bindings"
      ]
    }
  }
}

• Rolbindingen: een persoon koppelt ze opnieuw

  Het doel van elk account noemt stackit_authorization_project_role_assignment, dat de provider aanmerkt als onderdeel van een opt-in-functie iam die nog kan wijzigen. De run vertaalt roles/editor, roles/viewer of de custom role niet naar STACKIT-rollen; de run opent per account een reviewrecord.

• Sleutels: beslis of ze blijven bestaan

  Een langlevende JSON-sleutel wordt gemarkeerd. STACKIT-service accounts kunnen ook sleutels hebben, en de eigen pagina van STACKIT vermeldt dat u een sleutel voor de applicatie als een wachtwoord moet behandelen; Google zelf raadt sleutels af waar een veiliger alternatief bestaat. Beslis per aanroeper of die er nog een nodig heeft.

• De doelen van de bindingen worden als onbekend gelezen

  In deze run leest de engine een member die is geschreven als serviceAccount: plus het gegenereerde adres van het account als onbekende waarde, en kan dus niet tonen wie een binding noemt. Controleer de lijst met bindingen handmatig aan de hand van uw echte beleidsexport.

Hoe de Google-onderdelen worden gekoppeld

Rij twee tot en met zeven komen uit de lijst met ondersteunende resources in terraform/README.md en engineering/review.csv. Google zelf raadt aan basisrollen in productie te vermijden en meldt dat een custom role beperkt blijft tot het project of de organisatie waarin die is gemaakt.

De migratie in volgorde

1. 01

   Inventariseer principals en rechten

   Exporteer elk service account, elke sleutel, binding en custom role van de projecten die u migreert. De Terraform in de omgeving toont wat u als code beheert; bindingen die in de console of met andere tools zijn gemaakt staan er niet in, en de run kan ze niet zien.

2. 02

   Deel elk account in

   Verdeel accounts in runtime-identiteiten van applicaties, CI-identiteiten en door Google beheerde service agents. Voor de laatste groep hoeft meestal geen STACKIT-tegenhanger te worden gemaakt; bevestig dat per account.

3. 03

   Maak de accounts aan

   Pas de stackit_service_account-blokken toe. STACKIT-service accounts hebben standaard geen toegang; rechten komen uit rollen die in het project zijn toegewezen, dus er werkt niets totdat stap vier is gedaan.

4. 04

   Wijs rollen bewust toe

   Kies voor elke binding de STACKIT-rol met de minste rechten die het werk doet. De providerresource heeft resource_id, role en een subject in kleine letters nodig; beschikbare rollen worden uit de autorisatie-API gelezen.

5. 05

   Vervang sleutels door federatie

   Een STACKIT-service account kan een externe OIDC-issuer vertrouwen: de issuer-URL moet HTTPS zijn zonder slash aan het eind, een aud-claim is vereist en alleen gelijkheidsclaims worden ondersteund. De Terraform-provider zelf kan zo in CI authenticeren, waardoor een opgeslagen sleutel niet nodig is.

6. 06

   Richt workloads opnieuw in en ruim op

   Laat applicaties de nieuwe inloggegevens gebruiken, let op geweigerde aanroepen en verwijder de Google-accounts en -sleutels pas na een rustige periode. Een STACKIT-service account verwijderen is definitief, dus bewaar een export.

Beslissingen van de architect

• Het rolmodel

  Of u de rechten van Google spiegelt of opnieuw begint vanuit de STACKIT-rollen. Spiegelen neemt oude te ruime rechten over, zoals roles/editor.

• Waar workloads zich authenticeren

  Pods die de clusteridentiteit van Google gebruikten (de binding noemt een Kubernetes-service account in een projectpool) hebben op STACKIT geen equivalent totdat u hun issuer federeert of ze een sleutel geeft.

• Wie sleutels mag maken

  Een sleutel is een wachtwoord voor het account. Beslis wie er een mag uitgeven en waar die wordt bewaard voordat de eerste bestaat.

• Projectgrenzen

  De run plaatst elke resource in het ene project dat var.project_id aanwijst, en meldt dat een bron die over meerdere projecten is verdeeld daarin wordt samengevoegd. Bepaal hoeveel projecten u wilt, want roltoewijzingen gebeuren per project.

Vragen die securityteams stellen

Bronnen

• Google Cloud: overzicht van service accounts
• Google Cloud: best practices voor het beheren van sleutels van service accounts
• Google Cloud: overzicht van IAM-rollen
• Google Cloud: Workload Identity Federation voor GKE
• STACKIT: service accounts
• STACKIT: federaties van service accounts beheren
• STACKIT Terraform-provider v0.121.0: stackit_authorization_project_role_assignment
• STACKIT Terraform-provider v0.121.0: authenticatie en experimenten