Zenn
🎼

Azure デプロイスタックを試してみた

2024/07/13に公開
Azure
IaC
Bicep
tech

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) を用意します。

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