Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Tool endpoints use engine credentials for every caller instead of the per-user OBO branch

Đang mở
  • Có gì không ổn?
#387 1 bình luận 0 reaction 1 người được giao Xem trên GitHub

@DCMattyG đang làm issue này rồi.

Từ ngày 22/9/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

bug
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
  1. Deploy with at least one IPAM administrator configured (so the documented default-open bootstrap is closed).
  2. Sign in as a second tenant member holding no Azure RBAC on any subscription.
  3. POST /api/tools/cidrCheck with {"cidr": "10.0.0.0/8"} — returns 200 with vNets from subscriptions the caller cannot read: name, id, resource_group, subscription_id, address prefixes.
  4. Control: GET /api/azure/vnets for 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.

Ngôn ngữ chính
JavaScript
Star
326
Fork
111
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Azure/ipam

Tất cả issue của Azure/ipam

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.