Azure デプロイスタックを試してみた
Azure Deployment Stacks (デプロイスタック) が GA になったとのことで、試してみました😎
Azure デプロイ スタックは、Azure リソースのグループを 1 つのまとまりのある単位として管理できるリソースです。Bicep ファイルまたは ARM JSON テンプレートをデプロイ スタックに送信すると、スタックによって管理されるリソースが定義されます。
特筆すべきは、下記の 2 つの機能を有することです。
- テンプレートの記載からリソースが削除された場合、デプロイスタックにて指定された actionOnUnmanage の動作に基づいて、そのリソースはデタッチまたは削除される
- その他の Azure リソースと同様に、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、デプロイスタック内リソースへのアクセス制限を比較的簡単に構成できる
事前準備
作成したリソースの操作を拒否する制限を構成する場合、「Azure デプロイ スタック所有者」のロールが必要になります。
サブスクリプションの IAM から、当該ロールを操作アカウントへ付与しておいてください。
試してみる
Bicep ファイルの準備
Azure Cloud Shell を開き、チュートリアルに従って下記の Bicep ファイル (main.bicep) を用意します。
param resourceGroupLocation string = resourceGroup().location
param storageAccountName string = 'store${uniqueString(resourceGroup().id)}'
param vnetName string = 'vnet${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-04-01' = {
name: storageAccountName
location: resourceGroupLocation
kind: 'StorageV2'
sku: {
name: 'Standard_LRS'
}
}
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-11-01' = {
name: vnetName
location: resourceGroupLocation
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
subnets: [
{
name: 'Subnet-1'
properties: {
addressPrefix: '10.0.0.0/24'
}
}
{
name: 'Subnet-2'
properties: {
addressPrefix: '10.0.1.0/24'
}
}
]
}
}
デプロイしてみる
下記のコマンドを実行し、リソースグループを作成しつつデプロイスタックを構成していきます。
az group create --name 'demoRg' --location 'centralus'
az stack group create --name 'demoStack' --resource-group 'demoRg' \
--template-file './main.bicep' --action-on-unmanage 'detachAll' \
--deny-settings-mode 'denyWriteAndDelete'
--action-on-unmanage
オプションは、デプロイスタックからリソースの記述が削除された際に、該当のリソースをどうするか指定できます。
-
detachAll
: リソース、リソースグループ、管理グループをすべて削除せずに残します -
deleteAll
: リソース、リソースグループ、管理グループをすべて削除します -
deleteResources
: リソースのみを削除し、リソースグループと管理グループは削除せずに残します
--deny-settings-mode
オプションは、デプロイスタック外での設定を許容するかを指定できます。
-
denyWriteAndDelete
: リソースの設定変更も削除もできない -
denyDelete
: リソースの設定変更は可能だが、削除はできない -
none
: リソースの設定変更も削除も可能
手動でリソースを削除したり、設定を変更したりしてみる
手動でストレージアカウントのリソースを削除すると、エラーが発生します。
また、ネットワークの設定 (パブリックアクセスの許可など) を変更した場合も、同様にエラーが発生します。
--deny-settings-mode
オプションに denyWriteAndDelete
を指定していたので、想定通りですね!
この --deny-settings-mode
オプションの動作ですが、 --deny-settings-excluded-actions
で特定のアクションは実施可能にしたり、 --deny-settings-excluded-principals
オプションで除外するユーザー (プリンシパル) を設定したりすることも可能です。詳細についてはドキュメントを参照してみてください。
おわりに
基本的には手動でリソースの設定を変更してほしくない…という状況において、もちろん細かく IAM の設定をすれば実現は可能ですが、サクッとアクセス制御を構成できるのは便利だなと思いました。
なんというか、こういう「管理者があんまり難しいことをせずに構成できる/ただし動作のカスタマイズ性は最小限」ってところを出してくるのは Microsoft っぽいなーと思いました😁
Terraform の Azure Provider ではまだ対応していないようでしたが、Terraform (azurerm) からも使えるようになるといいですね!
Discussion