Migratie van OCI IAM, compartments en policies

Hoe de OCI-identiteitsobjecten overeenkomen

Elk OCI-object, het meest verwante STACKIT-concept en wat de run voor de demo-omgeving vastlegde. De STACKIT-kolom is ontwerpadvies uit de STACKIT-documentatie; de run noemt voor geen van deze objecten een doel.

Aantallen uit de run: 10 eenheden, alle MANUAL_REVIEW met zekerheidsniveau LOW. Zes zijn typen die de catalogus kent als identiteitsresources; vier staan niet in de catalogus. De reden die de run voor de zes geeft, is dat OCI-policies op STACKIT geen tegenhanger op documentniveau hebben.

Een compartment, een policy en een dynamische groep, beoordeeld

Een Oracle Cloud-identiteitsomgeving van tien resources, geschreven voor deze pagina en door StackToIT beoordeeld op 4 november 2026. Links drie blokken van de invoer. Rechts de beslissing die voor elk is vastgelegd. assessment.json staat op één regel, dus het venster toont geselecteerde velden van elke eenheid, ingesprongen en genest zoals in het bestand, met ongewijzigde waarden. De invoerblokken staan in aparte vensters omdat ze in main.tf niet naast elkaar staan.

resource "oci_identity_compartment" "prod" {
  compartment_id = var.tenancy_ocid
  name           = "prod"
  description    = "Production workloads"
}

resource "oci_identity_policy" "platform" {
  compartment_id = oci_identity_compartment.prod.id
  name           = "platform-manage-infra"
  description    = "Platform team manages compute and network in prod"
  statements = [
    "Allow group platform-team to manage instance-family in compartment prod",
    "Allow group platform-team to manage virtual-network-family in compartment prod",
  ]
}

resource "oci_identity_dynamic_group" "app_instances" {
  compartment_id = var.tenancy_ocid
  name           = "app-instances"
  description    = "Application instances in prod"
  matching_rule  = "ALL {instance.compartment.id = '${oci_identity_compartment.prod.id}'}"
}

[
  {
    "id": "oci_identity_compartment.prod",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_identity_compartment is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "oci_identity_policy.platform",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "OCI policies have no document-level counterpart on STACKIT. Map people and workloads to STACKIT roles and service accounts."
    }
  },
  {
    "id": "oci_identity_dynamic_group.app_instances",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_identity_dynamic_group is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  }
]

• Statements zijn tekst om te lezen

  De policy bevat twee statements die een groep en een compartment als strings noemen. De run noemt statements, name, description en compartment_id als instellingen die aan u zijn overgelaten en verplaatst niets; de statements één voor één lezen is het vertaalwerk.

• Het compartment is onbekend voor de run

  oci_identity_compartment staat in geen enkele catalogus van de hier gebruikte build, dus de run beoordeelt er niets voor en zegt dat waar het ertoe doet: de dynamische groep draagt een waarschuwing dat het eraan gekoppelde compartment niet is beoordeeld.

• Dynamische groepen zijn regels

  De matchingregel selecteert instances op compartment. Op STACKIT bestaat geen matchingregel: een service account wordt in een project aangemaakt en aan de workload toegewezen, dus de regel wordt een lijst met workloads die u moet uitrusten.

De volgorde die de run voorstelt

Eenheden staan in golven op basis van hun Terraform-verwijzingen. Let op wat een eenheid in golf 2 zet: de policy voor het platformteam hangt van het compartment af omdat compartment_id ernaar wijst. De databasepolicy noemt hetzelfde compartment alleen binnen een statementstring, dus die staat in golf 1.

## Wave 1 — 6 unit(s)

| Unit | Class | Target |
|---|---|---|
| `oci_identity_compartment.dev` | MANUAL_REVIEW / LOW | — |
| `oci_identity_compartment.prod` | MANUAL_REVIEW / LOW | — |
| `oci_identity_group.dba` | MANUAL_REVIEW / LOW | — |
| `oci_identity_group.platform` | MANUAL_REVIEW / LOW | — |
| `oci_identity_policy.dba` | MANUAL_REVIEW / LOW | — |
| `oci_identity_user.alice` | MANUAL_REVIEW / LOW | — |

## Wave 2 — 4 unit(s)

| Unit | Class | Target |
|---|---|---|
| `oci_identity_dynamic_group.app_instances` | MANUAL_REVIEW / LOW | — |
| `oci_identity_policy.app_secrets` | MANUAL_REVIEW / LOW | — |
| `oci_identity_policy.platform` | MANUAL_REVIEW / LOW | — |
| `oci_identity_user_group_membership.alice_platform` | MANUAL_REVIEW / LOW | — |

• Verwijzingen bepalen de volgorde, namen niet

  Groepsnamen in statements zijn strings, dus de run koppelt een policy niet aan zijn groepen. Bouw de volgorde zelf: eerst de structuur, dan subjects, dan rolbindingen, dan workloads en hun service accounts.

• Dit is geen planning

  De golven zijn een invoer voor uw plan. De handmatige stappen staan verzameld in execution/manual/actions.md. De gebruikers, groepen en policies liggen bij de Identity Architect; het pakket met de compartments, de dynamische groep en de namen van het groepslidmaatschap noemt geen eigenaar. Elke stap draagt een rollbackregel die zegt dat degene die de stap uitvoert, vastlegt hoe die ongedaan wordt gemaakt.

Vier manieren om de STACKIT-structuur op te zetten

De scope van een STACKIT-rolbinding is de organisatie, een map of een project. Een binding op één resource, zoals één bucket of één server, wordt niet ondersteund, en toegang is additief: een binding op een onderliggend niveau kan niet afnemen wat een bovenliggend niveau verleent.

Geen enkele optie bootst een diepe compartmentboom na. Nest uw tenancy compartments over meerdere niveaus, dan hoort afvlakken bij de beslissing en is het geen verlies dat de migratie veroorzaakt.

Hoe u kiest

Loop deze vragen door met de eigenaars van elk compartment. De antwoorden bepalen de optie hierboven.

1. 01

   1. Wie moet van wie gescheiden worden?

   Maak een lijst van de groepen en de compartments die ze raken. Twee groepen die elkaars resources niet mogen zien, hebben twee projecten nodig, omdat een rol niet onder projectniveau kan worden beperkt.

2. 02

   2. Welke statements worden echt gebruikt?

   Loop elk statement langs. Een statement over een resourcefamilie, bijvoorbeeld instance-family of database-family, kunt u benaderen met een brede rol als editor op een project, of met een productrol. Een statement dat van een where-voorwaarde afhangt, bijvoorbeeld een MFA-controle, vergt een beslissing over waar die controle op STACKIT hoort te liggen.

3. 03

   3. Waar komen mensen vandaan?

   STACKIT-gebruikersaccounts melden zich aan met een wachtwoord of via federatie. De STACKIT IdP-documentatie bevat handleidingen voor generiek OIDC, SAML 2.0, Microsoft Entra ID en Google Workspace, en voor SCIM-provisioning voor geautomatiseerde synchronisatie van gebruikers en groepen. Als praktijk geldt: uw bestaande provider federeren is minder werk dan gebruikers één voor één opnieuw aanmaken.

4. 04

   4. Welke workloads treden op als principals?

   Elke dynamische groep is een lijst van workloads die API's aanroepen. Maak voor elk een service account in het juiste project; dat heeft geen toegang totdat een rol is toegewezen. Workload identity federation met uw OIDC-issuer geeft kortlevende tokens zonder statische sleutel, terwijl een sleutelbestand zeer gevoelig is; toegangstokens van service accounts zijn deprecated.

5. 05

   5. Welke rollen verleent u?

   Voorgedefinieerde rollen zijn owner, editor en reader, plus productrollen zoals postgres-flex.admin die vooral voor service accounts bedoeld zijn. Als u een persoon alleen een productrol geeft, kunnen delen van het Portal ontoegankelijk blijven.

6. 06

   6. Hoe legt u het vast?

   Beheer de structuur als code met de STACKIT-Terraform-provider. Een project is een stackit_resourcemanager_project, en het label networkArea dat het in een Network Area plaatst, wordt bij het aanmaken ingesteld en kan later niet meer worden gewijzigd. Review de code zoals elke andere wijziging.

Beslissingen van uw architecten

• Projectgrenzen

  Het aantal en de vorm van de projecten, en de Network Area waartoe elk behoort. Deze keuze is achteraf het moeilijkst te wijzigen.

• Roltoewijzing

  Welke OCI-verbniveaus, van inspect via read en use tot manage, bij welke STACKIT-rollen horen. Er is geen één-op-één-tabel om toe te passen.

• Menselijke identiteit

  Een bestaande provider federeren of accounts aanmaken. Beslis wie eigenaar is van de levenscyclus van nieuwkomers en vertrekkers.

• Workloadidentiteit

  Sleutels of federatie per service account, en waar een secret staat.

• Break-glass-toegang

  Wie owner op de organisatie heeft en hoe die toegang wordt geauditeerd. De run beoordeelt dit niet.

• Cutovervolgorde

  Maak structuur en bindingen aan voordat workloads arriveren, zodat de eerste deployment geen uitzondering nodig heeft.

Vragen van identiteitsteams

Bronnen

• OCI IAM-policyreferentie: werkwoorden en resourcetypen
• OCI dynamische groepen
• STACKIT-rollen en -rechten
• STACKIT-organisaties en -mappen
• STACKIT-service accounts
• Resource stackit_resourcemanager_project, STACKIT-provider 0.121.0
• STACKIT IdP: federatie en provisioning