皆さん、こんにちは!
今回は Azure の RBAC 機能による権限管理を行う際に考慮する点や、つまずきやすいポイントを具体的なシナリオと絡めてご説明していきます。
今回は以下のようなシナリオで進めていきます。とりあえず IaaS 利用のみを想定しています。
イメージとしては下図のように、システム単位や部門単位で仮想マシン周りのコンピューティングリソースを管理して、ネットワークリソースを共用するような構成を想定します。
まずは、各リソースが所属するリソースグループの作成、リソースグループに紐づけるユーザーの作成を行います。今回のシナリオでは NW 管理ユーザー、VM管理ユーザー を用意します。
今回のシナリオではシンプルに「ネットワーク共同作成者 (Network Contributor)」の組み込みロールを割り当てた NW 管理ユーザーを、ネットワーク管理用のリソースグループのアクセス制御に追加します。ネットワーク共同作成者のロールを割り当てられたユーザーは、ロールを追加されたリソースグループ内でのネットワークの作成と管理が可能になります。
※組み込みロールの詳細については こちらを参照。
今回、仮想マシンはポータルの GUI から作成する想定です。該当ユーザーには「仮想マシン共同作成者 (Virtual Machine Contributor Contributor)」の組み込みロールをベースとしたカスタムロール(「VM Admin」とでも名付けます)を割り当て、VM 管理用のリソースグループのアクセス制御に追加します。このカスタムロールを割り当てられたユーザーは、ロールを追加されたリソースグループ内での仮想マシンの作成と管理が可能になります。 カスタムロールは PowerShell にて以下のコマンドで作成します。
$role = Get-AzureRmRoleDefinition "Virtual Machine Contributor"
$role.Id = $null
$role.Name = "VM Admin"
$role.Description = "<カスタムロールの説明>"
$role.Actions.Add("Microsoft.Compute/disks/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/<紐づける対象のサブスクリプションID>")
New-AzureRmRoleDefinition -Role $role
作成したカスタムロールをユーザーに割り当て、VM 管理用のリソースグループのアクセス制御に追加します。
「仮想マシン共同作成者」の組み込みロールには、ディスクリソースに関する権限が含まれていません。ポータルから作成する際には、特に指定する項目もないので、エラーも発生しませんが、後に仮想マシンにデータディスクを追加する必要が出てきた場合、該当組み込みロールの権限では作成ができないので、あらかじめカスタムロールに追加しておくのが良いでしょう。カスタムロールの作成についてはこちらをご参照ください。
今回はディスクリソースの権限を追加するため、以下のオペレーションを「仮想マシン共同作成者」の組み込みロールを元にしたカスタムロールに追加します。
Microsoft.Compute/disks/*
ロールの割り当てが完了したら、まずは NW 管理ユーザーにて、VNETを作成します。
特に問題なく作成が完了します。
次に VM 管理ユーザーにて、仮想マシンを作成するのですが、その前に、現状の権限ですと配置する VNET の情報を参照することすらできません。作成ウィザードを進めていき、VNET を選択する際に、選択できる VNET が1つもない状態になります。
理由は単純明快で、VM 管理ユーザーはネットワークリソースが配置されているリソースグループに対するアクセス制御を何も定義されていないからです。
「仮想マシン共同作成者」の組み込みロールの中身を見てみると、ネットワークリソースに関連する権限が、以下のように定義されています。
Microsoft.Network/applicationGateways/backendAddressPools/join/action | ネットワーク アプリケーション ゲートウェイのバックエンド アドレス プールの接続 |
Microsoft.Network/loadBalancers/backendAddressPools/join/action | ロード バランサーのバックエンド アドレス プールの接続 |
Microsoft.Network/loadBalancers/inboundNatPools/join/action | ロード バランサーの受信 NAT プールの接続 |
Microsoft.Network/loadBalancers/inboundNatRules/join/action | ロード バランサーの受信 NAT 規則の接続 |
Microsoft.Network/loadBalancers/read | ロード バランサーの読み取り |
Microsoft.Network/locations/* | ネットワークの場所の作成と管理 |
Microsoft.Network/networkInterfaces/* | ネットワーク インターフェイスの作成と管理 |
Microsoft.Network/networkSecurityGroups/join/action | ネットワーク セキュリティ グループの接続 |
Microsoft.Network/networkSecurityGroups/read | ネットワーク セキュリティ グループの読み取り |
Microsoft.Network/publicIPAddresses/join/action | ネットワーク パブリック IP アドレスの接続 |
Microsoft.Network/publicIPAddresses/read | ネットワーク パブリック IP アドレスの読み取り |
Microsoft.Network/virtualNetworks/read | 仮想ネットワークの読み取り |
Microsoft.Network/virtualNetworks/subnets/join/action | 仮想ネットワーク サブネットの接続 |
同一リソースグループ内に、ネットワークリソースが配置されている場合は、上記権限により VNET の参照や、VNET への参加が可能となりますが、今回のケースのようにネットワークリソースを別のリソースグループに配置している場合は、上記権限を割り当てたユーザーをネットワークリソースが配置されているリソースグループのアクセス制御に追加する必要があります。
上記権限を有するカスタムロール (「VNET Participant」と名付けます) を定義し、作成したカスタムロールを VM 管理ユーザーに割り当て、NW 管理用のリソースグループのアクセス制御に追加します。
改めて仮想マシンの作成ウィザードを進めていくと、今度は正しく先ほど作成した VNET が選択できるようになっています
仮想マシンの作成が無事完了し、ネットワーク / 仮想マシン でリソースグループを分けて、必要最低限の権限を割り当てた状態でそれぞれのリソースを構成することができました。
「~/join/action」のような、リソースに対して接続を行う権限は、接続される側のリソースが配置されているリソースグループ、或いはリソース自体にユーザーの割り当てが行われている必要があります。接続される側のリソースを参照する権限のみを有していて、接続する側のリソースが配置されているリソースグループ内で接続権限を有していても、アクションは失敗してしまいます。
今回は、作成するリソースの種類で大まかにリソースグループを分けて、それぞれのリソースグループに配置されるリソースに対して、構築作業における必要最低限の適切な権限を割り当てるケースにて権限管理を行う流れを簡単に紹介させていただきました。
RBAC を利用した権限管理は、突き詰めていけばどのような要件も満たせるのではないかと思うくらい柔軟に設定が可能なので、この記事をきっかけに、皆さんも是非、自分だけの RBAC を見つけてください。
次回予告