RBAC機能によるリソースアクセス制御

内苑利映

2017年12月08日

はじめに

皆さん、こんにちは！

今回は Azure の RBAC 機能による権限管理を行う際に考慮する点や、つまずきやすいポイントを具体的なシナリオと絡めてご説明していきます。

今回は以下のようなシナリオで進めていきます。とりあえず IaaS 利用のみを想定しています。

リソースグループを、ネットワーク / 仮想マシンで分割する
ネットワーク用リソースグループの管理者は、ネットワーク以外のリソースを作成できないようにしたい
仮想マシン用リソースグループの管理者は、仮想マシン以外のリソースを作成できないようにしたい

イメージとしては下図のように、システム単位や部門単位で仮想マシン周りのコンピューティングリソースを管理して、ネットワークリソースを共用するような構成を想定します。

まずは、各リソースが所属するリソースグループの作成、リソースグループに紐づけるユーザーの作成を行います。今回のシナリオでは NW 管理ユーザー、VM管理ユーザーを用意します。

NW 管理ユーザー

今回のシナリオではシンプルに「ネットワーク共同作成者 (Network Contributor)」の組み込みロールを割り当てた NW 管理ユーザーを、ネットワーク管理用のリソースグループのアクセス制御に追加します。ネットワーク共同作成者のロールを割り当てられたユーザーは、ロールを追加されたリソースグループ内でのネットワークの作成と管理が可能になります。

※組み込みロールの詳細についてはこちらを参照。

VM 管理ユーザー

今回、仮想マシンはポータルの 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」のような、リソースに対して接続を行う権限は、接続される側のリソースが配置されているリソースグループ、或いはリソース自体にユーザーの割り当てが行われている必要があります。接続される側のリソースを参照する権限のみを有していて、接続する側のリソースが配置されているリソースグループ内で接続権限を有していても、アクションは失敗してしまいます。