KI-Plattform: Zugriff und RBAC¶
Zugriff auf ein Foundry project bekommen drei Entra-ID-Gruppen pro project (Owner, Contributor, Reader) sowie die Identitäten des projects und deiner Anwendung. Alle Rollen sind Azure-RBAC-Rollen, die Terraform zuweist. Es gibt keine Schlüssel: Beim Foundry account ist die lokale Authentifizierung deaktiviert, und die Verbindungen nutzen Entra ID.
Wie Gruppen, PIM und Access Reviews auf der Plattform allgemein funktionieren, steht unter Zugriff, Gruppen und PIM und im Identitäts- und Zugriffsmodell.
Gruppen¶
| Gruppe | Zweck |
|---|---|
| Owner | Das project und seine Daten verwalten. Erhält außerdem data-plane-Rechte auf Project Storage, Search und Cosmos DB. |
| Contributor | Im project bauen: Agents erstellen, Dateien hochladen, mit dem Vector Store arbeiten. |
| Reader | Lesezugriff auf den Search-Index. |
Das project module nimmt die Object-IDs der Gruppen als Inputs owner_group_id, contributor_group_id und reader_group_id.
Rollen für die Gruppen¶
| Ressource | Owner-Gruppe | Contributor-Gruppe | Reader-Gruppe |
|---|---|---|---|
| Foundry project | Azure AI User | Azure AI User | |
| Project Storage Account | Storage Blob Data Owner | Storage Blob Data Contributor | |
| AI Search service | Search Service Contributor, Search Index Data Contributor | Search Service Contributor, Search Index Data Contributor | Search Index Data Reader |
| Cosmos DB account | Cosmos DB Operator, plus die SQL-Datenrolle auf den Collections des projects | Cosmos DB Operator, plus die SQL-Datenrolle auf den Collections des projects |
Die Reader-Gruppe bekommt im module keine Rolle auf dem project selbst, nur auf dem Search-Index. Ob das für deine Nutzung der Reader-Gruppe reicht, ist ein offener Punkt: Bekannte Probleme.
Gruppen-Inputs sind faktisch Pflicht
Die drei Gruppen-Inputs haben den Default null, aber die Rollenzuweisungen im module haben keine Bedingung. Wenn eine Gruppen-ID
fehlt, schlägt der plan fehl. Gib alle drei an.
Rollen für die project-Identität¶
Das project hat eine eigene user-assigned managed identity. Sie erhält die Rollen, die der Agent Service auf den Datenspeichern braucht:
| Ressource | Rollen der project-Identität |
|---|---|
| Storage Account | Storage Blob Data Owner |
| AI Search | Search Service Contributor, Search Index Data Contributor |
| Cosmos DB account | Cosmos DB Operator und die SQL-Datenrolle auf den fünf Collections des projects in der Datenbank enterprise_memory |
Als SQL-Rolle für Cosmos DB dient die eingebaute Rolle mit der ID 00000000-0000-0000-0000-000000000002. Die Collection-Rollen
werden zugewiesen, nachdem der Capability Host existiert, weil der Host die Collections erstellt. Das module wartet 60 Sekunden auf
die anderen Rollenzuweisungen, bevor es den Capability Host erstellt.
Rollen für die Workload-Identität¶
Das module workload_identity erstellt eine user-assigned managed identity für deine Anwendung und eine Liste von Rollenzuweisungen,
jeweils mit scope und role_definition_name. Die README des modules nennt diese Muster:
| Bedarf | Rolle |
|---|---|
| Dateien im Storage | Storage Blob Data Contributor (und Storage Queue Data Contributor für Queues) |
| Vector Store | Search Index Data Contributor, Search Service Contributor |
| State in Cosmos DB | Cosmos DB Operator, DocumentDB Account Contributor |
| Secrets | Key Vault Secrets User |
| Container Apps environment | Contributor |
Das sind Beispiele aus der README des modules, keine feste Menge. Gib der Anwendung nur die Rollen, die sie braucht, im kleinsten
Scope. Die Repository-Übersicht nennt die Rolle „Cognitive Services User“ als Beispiel für den Aufruf des accounts, aber das
module weist sie nicht von selbst zu: Ergänze sie in role_assignments, wo nötig.
Contributor auf dem environment
Das README-Beispiel gibt der Workload-Identität Contributor auf dem Container Apps environment. Das ist weit gefasst. Sieh es als Beispiel und stimme mit deinem Plattform-Team ab, ob du es brauchst.