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

Handle RBAC propagation when an already-granted permission is denied

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

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
azure, go
Lĩnh vực
authorization, cloud, security

Hướng nghiên cứu

Bắt đầu với TestTerraformACIWithInitialPermissions và lần theo các luồng phân tích lỗi cấp quyền, loại bỏ trùng lặp quyền và cập nhật vai trò mà nó thực thi. Sử dụng các tiêu chí chấp nhận để xác định khi nào hoàn tất: xử lý đúng các biến thể chữ hoa chữ thường và các hành động hỗn hợp, giới hạn số lần thử lại việc truyền bá mà không làm thay đổi vai trò, đồng thời bổ sung độ bao phủ kiểm thử đơn vị cho đầu vào tiếp tục, việc lọc và các timeout.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

MPF can receive an Azure AuthorizationFailed response for an action already present in the service principal's newly assigned custom role while Azure RBAC assignment or role-definition changes are still propagating.

MPF currently treats the response as a newly discovered permission, appends it to the result, updates the role, and increments the discovery iteration. Permission action strings are also compared and deduplicated case-sensitively, so variants such as:

Microsoft.Resources/subscriptions/resourcegroups/read
Microsoft.Resources/subscriptions/resourceGroups/read

can be returned as two permissions even though Azure RBAC action names are case-insensitive.

Evidence

TestTerraformACIWithInitialPermissions supplies all nine expected permissions initially but intermittently completes with one discovery iteration and ten raw permissions:

The initial custom role includes Microsoft.Resources/subscriptions/resourcegroups/read. After the five-second post-assignment wait, AzureRM can receive a 403 for Microsoft.Resources/subscriptions/resourceGroups/read. MPF records the differently cased action as new, updates the role, waits again, and succeeds.

Passing runs with the same provider versions demonstrate that the trigger is intermittent RBAC propagation rather than a new provider permission. The behavior predates Go 1.27.

Related to #231, which tracks eventual consistency after role detachment. This issue focuses on propagation after initial assignment and subsequent role updates.

Proposed behavior

  • Treat Azure RBAC action names as case-insensitive across result deduplication, role membership checks, invalid-action filtering, and resume-from-file inputs.
  • Define and preserve a stable canonical spelling in user-facing results.
  • When parsing authorization failures, split actions into already-granted and genuinely missing sets using case-insensitive comparisons.
  • Retry without role mutation or discovery-iteration increment only when all parsed actions are already granted at the relevant assignment scope.
  • If any parsed action is genuinely missing, add only those actions and continue normal discovery.
  • Account for wildcard actions, NotActions, deny assignments, and assignment scope so persistent denials are not misclassified as propagation lag.
  • Use bounded backoff with a separate propagation-retry counter and return an explicit timeout error.
  • Apply the behavior after initial role assignment and subsequent role-definition updates.
  • Avoid mutating caller-provided permission slice backing arrays while building updated roles.

Acceptance criteria

  • Casing variants of one Azure action appear once in MPF results and resume files.
  • A temporary denial for an already-granted action does not mutate the role or increment the discovery count.
  • Mixed authorization errors still add genuinely missing permissions.
  • Scope, wildcard, NotActions, and persistent-denial cases do not silently retry as propagation lag.
  • Retries are bounded, separately accounted for, and timeout failures are explicit.
  • Unit tests cover casing variants, eventual success, mixed actions, resume input, invalid-action filtering, and timeout behavior.
  • Existing genuine permission discovery remains unchanged.

A separate test-only PR will stabilize Terraform E2E assertions while this product behavior is designed and implemented. The E2E tolerance will remain visible in logs so this issue can track whether propagation lag continues occurring.

Ngôn ngữ chính
Go
Star
66
Fork
11
Merge trung bình
2 ngày 9 giờ
Pull request đã merge (30 ngày)
5

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

  • Không có Dockerfile hay 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/mpf

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

Issue tương tự

Thêm issue về Go

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.