LoginSignup
3
1

More than 3 years have passed since last update.

RBAC のカスタムロールの作成のやり方

Last updated at Posted at 2019-08-31

RBAC のカスタムロールの作成の仕方について具体的な設定例をまとめました。

ディレクトリロール と RBAC

Azure AD を使用する際、ディレクトリロールと RBAC (Resource Based Access Control) の違いがわからず混乱される方は多いと思います。
ディレクトリロールは Azure AD の機能 (ユーザー、グループ、条件付きアクセスなど Azure Portal の Azure Active Directory 項目配下) に対する権限設定であることに対し、RBAC は Azure 機能 (Azure Network など Azure AD の範囲を超えたもの) を利用するための権限設定です。

ここでは詳細は説明しませんが、以下の Microsoft ブログがとてもわかりやすくまとまっています。

従来のサブスクリプション管理者ロール、Azure RBAC ロール、および Azure AD 管理者ロール
https://github.com/MicrosoftDocs/azure-docs.ja-jp/blob/master/articles/role-based-access-control/rbac-and-directory-admin-roles.md

RBAC をもっと柔軟に利用したい

RBAC には共同管理者、所有者といったように既定で定められているロールがあります (以下の画面のロールの割り当ての追加)
しかしながら、場合によっては、既定のロールだと権限が強すぎたり、このロールでこの操作ができたら完璧なのに。。といったシチュエーションが少なからずあると思います。
pic27.png

そこでカスタムロールの出番です。

Step1. カスタムロールがどのような設定なのか理解する

まずはカスタムロールを設定する前に、RBAC がどのように設定されているものなのかを理解します。
Powershell で既定のロールである共同管理者とネットワーク協同作成者の設定を確認してみます。

Get-AzRoleDefinition | where Name -eq "Contributor"

Name             : Contributor
Id               : b24988ac-6180-42a0-ab88-20f7382dd24c
IsCustom         : False
Description      : Lets you manage everything except access to resources.
Actions          : {*}
NotActions       : {Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action, Microsoft.Blueprint/blueprintAssignments/write...}
DataActions      : {}
NotDataActions   : {}
AssignableScopes : {/}
Get-AzRoleDefinition | where Name -eq "Network Contributor"

Name             : Network Contributor
Id               : 4d97b98b-1d4f-4787-a291-c67834d212e7
IsCustom         : False
Description      : Lets you manage networks, but not access to them.
Actions          : {Microsoft.Authorization/*/read, Microsoft.Insights/alertRules/*, Microsoft.Network/*, Microsoft.ResourceHealth/availabilityStatuses/read...}
NotActions       : {}
DataActions      : {}
NotDataActions   : {}
AssignableScopes : {/}

なんとなくご理解いただけたと思いますが、Actions / NotActions に定義されたスコープが RBAC の実体となります。

共同管理者の場合、かなり強い権限となるため、Actions は [ * ] ですべてのスコープを定義しており、NotActions で操作できないスコープが定義されています。
一方、ネットワーク共同作成者はネットワーク関連のみ設定可能なロールとなるため、Actions にだけ実施可能なスコープが定義されています。

カスタムロールではこのように、実施したい (したくない) 操作を Actions (NotActions) のスコープに定義することによって柔軟な権限設定を実現します。

Step2. 実際に設定してみる

実際にカスタムロールを設定してみます。
今回は以下の要件を満たすカスタムロールを作成します。

  • 課金情報など含むサブスクリプション関連の情報は閲覧できないようにしたい
  • 閲覧/変更権限がほしい (削除はできないようにしたい)
  • 上記を個々のリソースではなく、指定したリソースグループ単位で付与させたい

上記の条件を Actions / NotActions に当てはめると以下のようになります。

// 基本的な操作を実施可能とするために追加

Actions : あらゆる種類のリソースの作成と管理
*

// 課金情報の閲覧をできないようにするために追加

Not Actions : 課金情報の読み取り
Microsoft.Billing//read
Microsoft.Commerce/
/read
Microsoft.Consumption/*/read

// 削除を実施不可能とするために追加

Not Actions : すべての削除
*/delete

課金情報の閲覧をできないようにするための設定ですが、こちらは Microsoft の公開資料を参照しました。
Billing Reader (課金情報閲覧者) という既定のルールがあるのですが、このロールでは課金情報の読み取りを行うために、以下の設定が Actions に追加されているので、逆にこの設定を NotActions に追加すれば課金情報が閲覧できなくなるはずです。

Azure リソースの組み込みロール
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles

課金情報の読み取り
Billing Reader
Microsoft.Billing//read
Microsoft.Commerce/
/read
Microsoft.Consumption/*/read

次に、メモ帳で JSON ファイルを作成します。

{
  "Name": "Test Custom Role",
  "Id": null,
  "IsCustom": true,
  "Description": "Test Custom Role",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "*/delete", 
    "Microsoft.Billing/*/read", 
    "Microsoft.Commerce/*/read", 
    "Microsoft.Consumption/*/read", 
  ],
  "AssignableScopes": [
    "/subscriptions/e55e4aa8-889c-4424-a88d-7f5XXXXXXX20/resourceGroups/test"
  ]
}

Name や Description は任意の記述を入力します。
IsCustome は true、Actions / NotActions は要件に応じたものを設定します。

subscriptions の設定は、ご自身で利用されているサブスクリプション ID を指定します。通常であれば以下のように設定すれば OK です。

"/subscriptions/e55e4aa8-889c-4424-a88d-7f5XXXXXXX20"

今回は [個々のリソースではなく、指定したリソースグループ単位で付与させたい] という要件があるので、以下のように指定をします。"test" という名前のリソース グループでのみ利用できるカスタムロールとして定義しています。
他のリソースグループでも利用できるようにしたいという場合は、カンマで区切って定義を増やしてください。

"/subscriptions/e55e4aa8-889c-4424-a88d-7f5XXXXXXX20/resourceGroups/test"

準備した JSON ファイルを Powershell で指定して実行します。

New-AzRoleDefinition -InputFile "C:\Users\admin\Desktop\customrole.json"

実行結果例
Name             : Test Custom Role
Id               : e6fabc8a-891a-4ae9-9ffd-21cb7b5798a7
IsCustom         : True
Description      : Test Custom Role
Actions          : {*}
NotActions       : {*/delete, Microsoft.Billing/*/read, Microsoft.Commerce/*/read, Microsoft.Consumption/*/read...}
DataActions      : {}
NotDataActions   : {}
AssignableScopes : {/subscriptions/e55e4aa8-889c-4424-a88d-7f5XXXXXXXX20/resourceGroups/test}

Step3. 設定を確認してみる

Azure ポータルにアクセスし、対象のリソースグループ (test) から アクセス制御 (IAM) の設定を確認します。
[ロールの割り当ての追加] で作成したカスタムロール “Test Custom Role” が追加されています。
pic28.png

このカスタムロールを付与したユーザーでサブスクリプション メニューをクリックしても、課金情報が表示されないことを確認します。
pic29.png

リソース グループ (test) 単位で権限を付与したので、上位階層であるサブスクリプション直下で RBAC の設定を行おうとすると、無効となり設定できません。
pic30.png

割り当てを行った自身のリソースグループ (test) のみ表示されることが確認できます。
pic31.png

自身のリソースグループ配下にリソースを作成できることを確認できます (Microsoft.RouteTable-...)
自身のリソースグループ配下のリソースを削除できないことを確認できます (Microsoft.RouteTable-...)
pic32.png

カスタムロールの更新の仕方

カスタムロールの更新は作成する場合と要領は同じです。
以下のように Set-azureAzRoleDefinition コマンドを実行すれば OK です。

Set-azureAzRoleDefinition -InputFile "C:\Users\nasekigu\Desktop\test.json"

JSON の中身も作成時とほとんど変わりません。
異なるのは "Id" に作成したカスタム ロールの Id を指定する必要があることだけです。
Actions / NotActions には更新後に利用するスコープをすべて記載してください。
新しいスコープだけ入れると設定前のスコープは削除されてしまうのでご注意ください。

設定内容抜粋
{
  "Name": "Test",
  "Id": "40a919ec-0571-439d-aaec-XXXX510357",
  "IsCustom": true,

その他詳細は Microsoft の公開資料をご参照いただければ。
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/custom-roles
https://docs.microsoft.com/ja-jp/azure/role-based-access-control/custom-roles-powershell

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1