Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Handle RBAC propagation when an already-granted permission is denied

オープン
  • 何か問題がありますか？
#334 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
azure, go
領域
authorization, cloud, security

調査の方向性

TestTerraformACIWithInitialPermissions から始め、それが実行する認可失敗の解析、権限の重複排除、ロール更新の各パスを追跡します。受け入れ条件を完了の定義に使用します。大文字と小文字のバリエーションおよび混在したアクションを正しく処理し、ロールを変更せずに伝播の再試行回数に上限を設け、resume input、フィルタリング、タイムアウトのユニットテストカバレッジを追加します。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Go
スター
66
フォーク
11
平均マージ
4時間 30分
マージ済み PR（30日）
6

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Azure/mpf のほかの issue

Azure/mpf の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。