Azure / Azure/azure-rest-api-specs

[BUG] AzureDevOpsPermissionType "CreatorOnly" is accepted by API but behaves as "Inherit"

Open
#41,786 0 comments 1 reaction 0 assignees View on GitHub
bug customer-reported question
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.