はじめに
こちらの後半です。
こちらを入り口としたAzure DevOpsの権限まわりを理解するための記事となります。
認証とアクセスレベルの話題は前の記事で理解できたと思います。
認証はマイクロソフトアカウントやAzure AD、GitHub等を介した個体認証、アクセスレベルは購入しているライセンスに沿った利用範囲のお話しでした。
この記事では、認可の部分を掘り下げていきます。
結論
・認証、認可、ライセンスの３段構えが存在する
・Azure ADが使える
・個々のサービス単位での権限が存在する
ここらへんがフンワリわかっていれば、以降は読まなくて大丈夫です。
誰に何を許可する
登場人物を整理します。
誰に - セキュリティグループ
機能への許可もしくは拒否を設定するグループです。
個人単位での設定も可能ですが、現実的ではありません。
ユーザーは必ずどこかのセキュリティグループに所属しますので、正しく利用しましょう。
具体的な例
Organization SetteingsのSecurity - Permissionsの"Groups"を表示しました。
詳細はこちらをご確認ください。
余談ですが、Collectionという言葉は気にしないでください。オンプレのなごりだと思って放置しましょう。
プロジェクトを束ねているものの表現なので、Collection ＝ 組織(Organization)という理解でドキュメントは読み進めていただいてとりあえず大丈夫です。
何を - 組織、プロジェクト、オブジェクト
"どんなことを許可するのか"を考える際、１番最初に認識するべきは、"組織(Organization)","プロジェクト","オブジェクト"です。
図にするとこんな感じです。
もっとも大きな単位が"組織"となります。
プロジェクト単位では扱うことのできない、またプロジェクト単位のユーザーが扱うべきではない作業の権限を設定するのが"組織"になります。
プロジェクトは個々のプロジェクトの単位で、オブジェクトは個々のオブジェクトの単位で設定することとなります。
ドキュメント上、オブジェクトだけは抽象的にオブジェクトと表現していますのでご認識ください。
詳細はこちらをご確認ください。
（さっきのリンクと同じドキュメントの後半に書いてあります。）
ここまでのまとめ
個人をセキュリティグループに所属させ、セキュリティグループに対して組織・プロジェクト・オブジェクトの各々で許可すること、拒否することを設定するのが認可の基本的な部分。
Azure AD
セキュリティグループを作成する際
- 大人数
- 組織やプロジェクトが大量
- 会社のルールで縛りたい
といった時は、Azure ADと接続しましょう。
Azure ADと接続すれば、Azure AD側で設定されたグルーピングあれこれを流用できます。
人の出入り１つ取っても、離脱時の削除は忘れがちなので、Azure ADで管理する方法が適している場合があります。
多要素認証とか接続許可IPアドレスとか、会社のルールを意識した場合にAzure AD利用が必須となるお客様もいらっしゃいます。
ご利用の際は、こちらを参考にして設定いただけたらと思います。
全社利用のAzure ADを接続したら会社のルールでパートナーさんを入れられないとか、そういったことも発生しますので、ご利用は計画的に。
規定のセキュリティグループから学ぶ
Azure DevOpsは、最初から規定のグループができています。
ここでは"プロジェクト"レベルの規定のグループからセキュリティグループ同士の関係性を見ていきます。
プロジェクトレベルの規定のグループ
各々が何を意識しているのか、日本語の詳細はこちらのドキュメントをご確認ください。
※さっきから同じドキュメントの中をご案内しています。
例えばContributors(共同作成者)グループをクリックするとこのような画面になると思います。
画面の上部4つのタブ"Permissions", "Members", "Member of", "Settings"が確認できると思います。
Permissions：アクセス許可の管理、そのグループに対する権限の継承・与奪を管理
Members：メンバーシップの管理、所属しているグループや個人を管理
Member of：メンバーシップの管理、自身の親となっているグループを管理
Settings：自身の設定(グループ名や説明文等)
この記述から、グループは親子関係が作れる上に複数の親も存在し得ることがわかります。
規定の6グループの関係性を図にするとこのような関係性となっています。
全ての起点となるのは"Project Valid Users"となります。
各々の権限がどうなっているのかを確認するためにスクリーンショットを切り貼りしました。
左から"Project Valid Users", "Build Administrators", "Contributors", "sampleprivateprj001(Teamname)"のPermissionsを並べています。
全ての起点となっているProject Valid Usersでは、AnalyticsだけAllow(許可)になっていて、あとはNot set(未設定)となっています。
メンバーの１つであるBuild Administratorsではまず、AnalyticsがAllow(inherited)(継承された許可)になっています。またTest Plansを中心として、Allow(system)(システム上設定された許可)になっています。先のドキュメント内、ビルド管理者のアクセス許可の説明にも以下の記載がありますので、それに従った設定と想像できます。
プロジェクトのビルド リソースとビルド アクセス許可を管理するためのアクセス許可を持っています。 メンバーは、テスト環境の管理、テストの実行の作成、ビルドの管理を実行できます。
次にContributorsを確認します。
AnalyticsについてはAllow(inherited)ですので、Project Valid Usersから引き継いで許可されています。
Build Administratorsとよく似た設定内容となっていますが、Allow(system)ではなくAllowであること(編集可)や、work itemsの削除に対する明示的なAllow(許可)に特徴があります。
Contributorsは普段作業するメンバーが所属するグループなので、作業を記載したwork itemsについて、間違った時は削除できる権限が欲しいですよね。このAllowは理にかなっていると思います。
最後にTeamname(今回は"sampleprivateprj001")ですが、こちらは基本的にAllow(inherited)(継承された許可)かNot set(未設定)です。
このチーム独自の許可、拒否が存在する場合はここで設定することになります。
権限の種類
権限は、
- Allow(許可)
- Deny(拒否)
- 親から引き継いだAllow(inherited)(継承された許可)
- 親から引き継いだDeny(inherited)(継承された拒否)
- 設定に関与しない(親に任せる)Not set(未設定)
があります。
親がAllowで自分がNot setだとAllow(inherited)になります。
複数の親から権限を受け継いだらどうなる
詳細はこちらに記載がありますのでご確認ください。
アクセス許可の継承とセキュリティグループの項となります。
ただ、日本語が怪しいので要約を書きます。
- 自分で上書きしたら上書きの勝ち
- 親AからAllow、親BからDenyを受け取ったら親Bの勝ち(Deny優先)
- 区分(AreaPath)やイテレーションのような階層構造がある場合自分に１番近い階層の設定を引き継ぐ
- 区分(AreaPath)やイテレーションのような階層構造がある場合も自分で上書きしたら上書きの勝ち
まとめ
今回はAzure DevOpsの権限まわりの基本的な部分に触れました。
- 認証したらライセンスが確認され、アクセスレベルが決まる(Basic,ステークホルダー,Test)
- 認証したら所属するセキュリティグループに従って作業可否が決まる
- セキュリティグループはAzure ADのグループも使える
- 既定のセキュリティグループがあるので意図を見る
- PermissionsはAllowかDeny、親から継ぐか自分で選択する
ここまでがわかれば、あとは組み合わせと個々のオブジェクト単位の設定なので、必要な部分をドキュメントから探していきましょう。
このページから始まるドキュメント一式に、きっと知りたい情報があると思います。
