OCI IAM, Compartments und Policies migrieren

Wie die OCI-Identitätsobjekte zusammenpassen

Jedes OCI-Objekt, das nächstliegende STACKIT-Konzept und was der Lauf für die Demo-Umgebung festgehalten hat. Die STACKIT-Spalte ist eine Entwurfshilfe auf Basis der STACKIT-Dokumentation; der Lauf nennt für keines dieser Objekte ein Ziel.

Zahlen aus dem Lauf: 10 Einheiten, alle MANUAL_REVIEW bei niedriger Konfidenz. Sechs sind Typen, die der Katalog als Identitätsressourcen kennt; vier stehen nicht im Katalog. Als Grund nennt der Lauf für die sechs, dass OCI-Policies auf STACKIT kein Gegenstück auf Dokumentebene haben.

Ein Compartment, eine Policy und eine Dynamic Group, bewertet

Eine Oracle-Cloud-Identitätsumgebung mit zehn Ressourcen, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links drei Blöcke der Eingabe. Rechts die jeweils festgehaltene Entscheidung. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten. Die Eingabeblöcke stehen in getrennten Ausschnitten, weil sie in main.tf nicht direkt aufeinander folgen.

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)."
    }
  }
]

• Anweisungen sind zu lesender Text

  Die Policy trägt zwei Anweisungen, die eine Gruppe und ein Compartment als Strings nennen. Der Lauf führt statements, name, description und compartment_id als Ihnen überlassene Einstellungen und verändert nichts; die Anweisungen einzeln zu lesen ist die Übersetzungsarbeit.

• Das Compartment ist dem Lauf unbekannt

  oci_identity_compartment steht in keinem Katalog des hier genutzten Builds; daher bewertet der Lauf dafür nichts und sagt das dort, wo es zählt: Die Dynamic Group trägt eine Warnung, dass das mit ihr verbundene Compartment nicht bewertet wird.

• Dynamic Groups sind Regeln

  Die Matching-Regel wählt Instanzen nach Compartment aus. Auf STACKIT gibt es keine Matching-Regel: Ein Service Account wird in einem Projekt angelegt und dem Workload zugewiesen; die Regel wird also zu einer Liste von Workloads, die Sie ausstatten.

Die vorgeschlagene Reihenfolge

Die Einheiten liegen in Wellen nach ihren Terraform-Referenzen. Achten Sie darauf, was eine Einheit in Welle 2 bringt: Die Policy des Plattformteams hängt vom Compartment ab, weil ihre compartment_id darauf zeigt. Die Datenbank-Policy nennt dasselbe Compartment nur in einem Anweisungs-String und liegt deshalb in Welle 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 | — |

• Referenzen ordnen, Namen nicht

  Gruppennamen in Anweisungen sind Strings; daher bindet der Lauf eine Policy nicht an ihre Gruppen. Legen Sie die Reihenfolge selbst fest: zuerst die Struktur, dann die Subjekte, dann die Rollenzuweisungen, dann Workloads und ihre Service Accounts.

• Nichts davon ist ein Zeitplan

  Die Wellen sind eine Eingabe für Ihren Plan. Die manuellen Schritte stehen gesammelt in execution/manual/actions.md. Benutzer, Gruppen und Policies liegen beim Identity Architect; das Paket mit den Compartments, der Dynamic Group und der Gruppenmitgliedschaft nennt keinen Verantwortlichen. Jeder Schritt trägt eine Rollback-Zeile, nach der die ausführende Person selbst festhält, wie er rückgängig gemacht wird.

Vier Wege, die STACKIT-Struktur aufzubauen

Der Geltungsbereich einer STACKIT-Rollenzuweisung ist die Organisation, ein Ordner oder ein Projekt. Eine Zuweisung auf einer einzelnen Ressource wie einem Bucket oder einem Server wird nicht unterstützt, und Zugriff ist additiv: Eine Zuweisung auf einer untergeordneten Ebene kann nicht entziehen, was eine übergeordnete gewährt.

Keine Option bildet einen tiefen Compartment-Baum ab. Verschachtelt Ihre Tenancy Compartments über mehrere Ebenen, gehört das Abflachen zur Entscheidung und ist kein Verlust, den die Migration verursacht.

So entscheiden Sie

Gehen Sie diese Fragen mit den Verantwortlichen jedes Compartments durch. Die Antworten bestimmen, welche der Optionen oben passt.

1. 01

   1. Wer muss von wem getrennt sein?

   Listen Sie die Gruppen und die Compartments auf, die sie berühren. Zwei Gruppen, die ihre Ressourcen gegenseitig nicht sehen dürfen, brauchen zwei Projekte, denn eine Rolle lässt sich nicht unter ein Projekt eingrenzen.

2. 02

   2. Welche Anweisungen werden wirklich genutzt?

   Gehen Sie jede Anweisung durch. Eine Anweisung über eine Ressourcenfamilie, etwa instance-family oder database-family, lässt sich durch eine breite Rolle wie editor auf einem Projekt oder durch eine Produktrolle annähern. Hängt eine Anweisung an einer where-Bedingung, zum Beispiel einer MFA-Prüfung, entscheiden Sie, wo diese Kontrolle auf STACKIT liegt.

3. 03

   3. Woher kommen die Personen?

   STACKIT-Benutzer melden sich mit Passwort oder über Föderation an. Die Dokumentation zum STACKIT IdP enthält Anleitungen für generisches OIDC, SAML 2.0, Microsoft Entra ID und Google Workspace sowie SCIM-Provisioning für die automatische Synchronisierung von Benutzern und Gruppen. Als Praxis gilt: Ihren bestehenden Provider zu föderieren ist weniger Arbeit, als Benutzer einzeln neu anzulegen.

4. 04

   4. Welche Workloads handeln als Principals?

   Jede Dynamic Group ist eine Liste von Workloads, die APIs aufrufen. Legen Sie für jeden einen Service Account im richtigen Projekt an; er hat keinen Zugriff, bis eine Rolle zugewiesen ist. Workload Identity Federation mit Ihrem OIDC-Issuer liefert kurzlebige Tokens ohne statischen Schlüssel, während eine Schlüsseldatei hochsensibel ist; Zugriffstokens von Service Accounts sind abgekündigt.

5. 05

   5. Welche Rollen vergeben Sie?

   Vordefiniert sind owner, editor und reader sowie Produktrollen wie postgres-flex.admin, die überwiegend für Service Accounts gedacht sind. Erhält eine Person nur eine Produktrolle, können Teile des Portals unzugänglich bleiben.

6. 06

   6. Wie halten Sie es fest?

   Halten Sie die Struktur mit dem STACKIT-Terraform-Provider im Code fest. Ein Projekt wird als Ressource stackit_resourcemanager_project angelegt, und das Label networkArea, das es einer Network Area zuordnet, wird beim Anlegen gesetzt und lässt sich danach nicht mehr ändern. Prüfen Sie den Code wie jede andere Änderung.

Entscheidungen Ihrer Architekten

• Projektgrenzen

  Zahl und Zuschnitt der Projekte und die Network Area, der jedes Projekt angehört. Diese Wahl lässt sich später am schwersten ändern.

• Rollenzuordnung

  Welche OCI-Verb-Stufen, von inspect über read und use bis manage, welchen STACKIT-Rollen entsprechen. Eine Eins-zu-eins-Tabelle zum Anwenden gibt es nicht.

• Menschliche Identität

  Einen bestehenden Provider föderieren oder Konten anlegen. Entscheiden Sie, wer den Lebenszyklus von Ein- und Austritten verantwortet.

• Workload-Identität

  Schlüssel oder Föderation je Service Account, und wo ein Secret liegt.

• Notfallzugriff

  Wer owner auf der Organisation hält und wie dieser Zugriff geprüft wird. Der Lauf bewertet das nicht.

• Reihenfolge beim Cutover

  Legen Sie Struktur und Zuweisungen an, bevor Workloads eintreffen, damit der erste Deploy keine Ausnahme braucht.

Fragen von Identity-Teams

Quellen

• OCI-IAM-Policy-Referenz: Verben und Ressourcentypen
• OCI: Dynamic Groups
• STACKIT-Dokumentation: Rollen und Berechtigungen
• STACKIT-Dokumentation: Organisationen und Ordner
• STACKIT-Dokumentation: Service Accounts
• Ressource stackit_resourcemanager_project, STACKIT-Provider 0.121.0
• STACKIT IdP: Föderation und Provisioning