AI Platform: Access and RBAC¶
Access to a Foundry project is given to three Entra ID groups per project (owner, contributor, reader) and to the identities of the project and of your application. All roles are Azure RBAC roles assigned by Terraform. There are no keys: the Foundry account has local authentication disabled and the connections use Entra ID.
For the generic way groups, PIM and access reviews work on the platform, see Access, groups and PIM and the identity and access model.
Groups¶
| Group | Purpose |
|---|---|
| Owner | Manage the project and its data. Also receives data-plane rights on the project storage, search and Cosmos DB. |
| Contributor | Build in the project: create agents, upload files, work with the vector store. |
| Reader | Read access to the search index. |
The project module takes the group object IDs as inputs owner_group_id, contributor_group_id and reader_group_id.
Roles for the groups¶
| Resource | Owner group | Contributor group | Reader group |
|---|---|---|---|
| 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 the SQL data role on the project's collections | Cosmos DB Operator, plus the SQL data role on the project's collections |
The reader group gets no role on the project itself in the module, only on the search index. Whether that is enough for your use of the reader group is an open point: Known issues.
Group inputs are effectively required
The three group inputs default to null, but the role assignments in the module have no condition. If a group ID is
not supplied, the plan fails. Supply all three.
Roles for the project identity¶
The project has its own user-assigned managed identity. It receives the roles that the agent service needs on the data stores:
| Resource | Roles of the project identity |
|---|---|
| Storage account | Storage Blob Data Owner |
| AI Search | Search Service Contributor, Search Index Data Contributor |
| Cosmos DB account | Cosmos DB Operator, and the SQL data role on the five collections of the project in database enterprise_memory |
The SQL role used for Cosmos DB is the built-in role with ID 00000000-0000-0000-0000-000000000002. The collection roles
are assigned after the capability host exists, because the host creates the collections. The module waits 60 seconds for
the other role assignments before it creates the capability host.
Roles for the workload identity¶
The workload_identity module creates a user-assigned managed identity for your application and a list of role
assignments, each with a scope and a role_definition_name. The module README gives these patterns:
| Need | Role |
|---|---|
| Files in storage | Storage Blob Data Contributor (and Storage Queue Data Contributor for 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 |
These are examples from the module README, not a fixed set. Give the application only the roles it needs, at the smallest
scope. The repository overview mentions the role "Cognitive Services User" as an example for calling the account, but the
module does not assign it by itself: add it to role_assignments where needed.
Contributor on the environment
The README example gives the workload identity Contributor on the Container Apps environment. This is broad. Treat it as an example and agree with your platform team whether you need it.