Tool endpoints use engine credentials for every caller instead of the per-user OBO branch
@DCMattyG is already working on this.
Since Sep 22, 2026.
Assessment
This issue has not been assessed yet.
Description
Summary
The three user-facing tool endpoints always query Azure with the engine's own credentials regardless of who is calling, while every equivalent routed endpoint correctly branches between engine credentials (administrators) and the caller's on-behalf-of credentials (everyone else). The result contradicts the documented authorization model, in which non-admin users only see resources they already have access to.
Observed
Line references are against current main (12e41f4).
engine/app/routers/tool.py passes a hardcoded True as the admin argument:
nextAvailableSubnet—arg_query(authorization, True, argquery.VNET)(tool.py:73)nextAvailableVNet—get_network(authorization, True)(tool.py:162)cidrCheck—arg_query(authorization, True, argquery.NET_BASIC)(tool.py:239)
In engine/app/routers/common/helper.py (lines 277-311), admin=True selects get_client_credentials() — the engine app registration, which the deployment grants Reader at the management group (tenant root by default). admin=False builds an OnBehalfOfCredential from the caller's token, so the caller sees only what their own Azure RBAC permits.
The same defect appears a second time through a positional-binding bug: get_network's second positional parameter is tenant_id, so get_network(authorization, True) binds tenant_id=True and leaves admin at its default — an unresolved Depends(get_admin) marker, which is truthy — again selecting engine credentials. This shape is present on the reservation-create path (~line 2956) and the spaces-utilization path in engine/app/routers/space.py.
For contrast, the routed endpoints do this correctly: get_vnet in engine/app/routers/azure.py declares admin: str = Depends(get_admin) and passes the resolved flag through to arg_query.
Expected vs actual
docs/how-to/README.md states the model:
It uses your existing Azure AD credentials to authenticate you and leverages your existing Azure RBAC permissions to authorize what information is visible from within the IPAM tool.
Once at least one IPAM administrator is set, non-admin users will only see resources in IPAM they already have access to from the Azure Portal.
Actual: a non-admin tenant member holding no Azure RBAC on any subscription can call the three tool endpoints and receive the engine's Reader-level view of the management group.
Repro sketch
- Deploy with at least one IPAM administrator configured (so the documented default-open bootstrap is closed).
- Sign in as a second tenant member holding no Azure RBAC on any subscription.
POST /api/tools/cidrCheckwith{"cidr": "10.0.0.0/8"}— returns 200 with vNets from subscriptions the caller cannot read: name, id, resource_group, subscription_id, address prefixes.- Control:
GET /api/azure/vnetsfor the same caller returns the caller's own (empty) view, since that route resolves the admin flag. The differential between the two responses is the issue.
nextAvailableSubnet additionally acts as an existence oracle for any named vNet id (400 "Virtual Network not found" vs 200) and discloses its vnet_name / resource_group / subscription_id; iterating size probes maps a target vNet's subnet layout.
Suggested fix
Resolve the admin flag on the three tool handlers (declare admin: str = Depends(get_admin) and pass it through), mirroring azure.py. At the get_network call sites, pass admin by keyword — the current positional True also corrupts tenant_id. The same hardcoded True is still present on the ipam-3.7.0 branch of #377, so the release PR does not currently cover this.
- Dominant language
- JavaScript
- Stars
- 326
- Forks
- 111
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/ipam
-
nextAvailableVNet fails when using multiple blocks and smallest_cidr option true if no IP range is available in first blockPossibly taken @DCMattyG claimed this 63 days ago. Openbug
-
Overlap in CIDRPossibly taken @DCMattyG claimed this 221 days ago. Openbug
-
Standalone NICs not listed in Endpoint nodePossibly taken @DCMattyG claimed this 308 days ago. Openbug
-
Planner will not loadPossibly taken @DCMattyG claimed this 370 days ago. Openbug
-
Error fetching available IP Block networksPossibly taken @DCMattyG claimed this 494 days ago. Openbug
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
developmentseed/deck.gl-raster#693 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
dependencies security
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
dev experience
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
cuttle-cards/cuttle#1413 ·
Maintainers usually reply within 1 day
-
macOS
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
beyondcode/herd-community#1761 ·