Azure / Azure/azure-rest-api-specs
[BUG] AzureDevOpsPermissionType "CreatorOnly" is accepted by API but behaves as "Inherit"
- Dominant language
- TypeSpec
- Stars
- 3.1k
- Forks
- 5.9k
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 424
Description
### API Spec link
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/devopsinfrastructure/Microsoft.DevOpsInfrastructure/tspconfig.yaml
### API Spec version
2025-01-21
### Describe the bug
When creating a Managed DevOps Pool (Microsoft.DevOpsInfrastructure/pools) using a Service Principal with organizationProfile.permissionProfile.kind set to "CreatorOnly", the API accepts the request and returns "CreatorOnly" in the response. However, the actual behavior is identical to "Inherit" — permissions are inherited from the Azure DevOps project/organization, and the Service Principal (creator) does not automatically receive admin permissions on the pool.
This issue does not occur when using a user account; it only manifests with Service Principal authentication.
Additionally, permissionProfile cannot be modified after pool creation, so there is no way to correct this without destroying and recreating the pool.
"Inherit" and "SpecificAccounts" work as expected regardless of the authentication method.
### Expected behavior
When permissionProfile.kind is set to "CreatorOnly", the pool should grant the pool creator admin permissions and not inherit permissions from the parent Azure DevOps project/organization — matching the semantics described in the enum value name.
### Actual behavior
- The API accepts "CreatorOnly" without error.
- The API returns "CreatorOnly" in GET responses.
- The actual runtime behavior is identical to "Inherit" (permissions are inherited from the Azure DevOps org/project; the creator does not get special admin access).
- The permissionProfile is immutable after creation, so the misconfigured pool must be destroyed and recreated.
### Reproduction Steps
1. Authenticate as a Service Principal (e.g., via az login --service-principal
2. Create a Microsoft.DevOpsInfrastructure/pools resource via the 2025-01-21 API with:
```
{
"properties": {
"organizationProfile": {
"kind": "AzureDevOps",
"permissionProfile": {
"kind": "CreatorOnly"
},
"organizations": [
{
"url": "https://dev.azure.com/",
"parallelism": 1
}
]
}
}
}
```
3. Observe the API returns 200 OK with permissionProfile.kind = "CreatorOnly".
4. In Azure DevOps, navigate to the created agent pool's security settings.
5. Observe that permissions are inherited from the project/organization (same as "Inherit" behavior) and the Service Principal has no admin role on the pool.
### Environment
_No response_
Contributor guide
Research direction
Start by reviewing the Microsoft.DevOpsInfrastructure API definition in the linked tspconfig.yaml for API version 2025-01-21 and the permissionProfile enum. Reproduce the behavior with az login --service-principal and a Microsoft.DevOpsInfrastructure/pools request, then verify whether the specification needs correction or the service behavior must change so CreatorOnly grants the creator pool administration without inherited permissions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- api, authorization
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100