今回説明する Storage Account について
新規で Standard Logic Apps リソースをデプロイされる際、既存 Storage Account の選択、もしくは Storage Account の新規作成が必須になっています。
この Storage Account には Logic Apps のワークフロー情報、実行履歴等を保存する役割があります。
端的に、Logic Apps Standard を作成した際に一緒に作成されるコンテナやファイルは、Logic Apps Standard をご利用の際のワークフロー情報や、実行履歴情報が格納されているものとなります。
Logic Apps Standard と関連するストレージ アカウント # Logic Apps Standard を作成した際に一緒に作成されるストレージ アカウントの役割
下記画像にもあるように、当該 Storage Account への接続はアクセス キーの認証となっています。
- AzureWebJobsStorage
- WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
上記 2 つの環境変数が Standard Logic Apps から Storage Account にアクセスするにあたって、必須のものとなっています。環境変数の詳細は以前執筆した下記記事をご参照ください。
※注意ある程度調べたつもりですが、もしかしたら私の認識が違う箇所があるかもしれません。「これ違うんじゃない？」というものがあったら、コメントいただけますと幸いです。 凄く重要な前提 Standard Logic Apps は[…]
接続にアクセス キーを使う際の問題
アクセス キーでも認証はしっかりとされていますし、一見、問題が無いように思えます。
しかしながら、こちらのアクセス キーを使った認証については、資格情報が漏洩してしまった際のリスクを考慮して、定期的にアクセス キーを再生成することが Microsoft より推奨されています。
キーのローテーションと再生成は定期的に行うことをお勧めします。
また、企業によっては社内セキュリティ ポリシー上、毎月や数ヶ月に 1 度という頻度でアクセス キーが変更されるといった状況も考えられます。
その場合はアクセス キーで認証している Standard Logic Apps の環境変数も変更する必要がありますが、手動で行うには些かめんどくさいため、別の方法を採用したいところです。
この際、真っ先に候補として挙がるのがセキュリティ性の高いマネージド ID を使った認証方法です。
Microsoft では、可能な限り、Microsoft Entra ID とマネージド ID を使って、BLOB、キュー、テーブルのデータに対する要求を認可することをお勧めします。 Microsoft Entra ID とマネージド ID を使った認可によって、共有キー認可よりもセキュリティが向上し、使いやすくなります。
上記から、本記事では Standard Logic Apps の情報保存先である Storage Account に対して、マネージド ID での認証・認可を行う方法を試してみたいと思います。
Storage Account にマネージド ID で接続
結論
無駄に時間を使わせてしまうのも好ましくないので、少し順番を入れ替えて、『結論 ⇒ 検証をもとにした理由 ⇒ もしかしたらの回避策』という順番でご説明します。
結論から申し上げますと、Standard Logic Apps から Storage Account に接続をするにあたって、アクセス キーではなくマネージド ID を使用することは出来ません。
理由として、Standard Logic Apps の構成に必要な 2 つの環境変数のうち『AzureWebJobsStorage』はマネージド ID に対応しているものの、『WEBSITE_CONTENTAZUREFILECONNECTIONSTRING』に使われている Azure Files がマネージド ID 非対応だったからです。
ここからは検証パートに入りますので、回避策だけ知りたい方は飛ばしていただいて結構です。
検証
今回はサンプルとして、接続先の Storage Account 名は『testrga42e』となっています。
マネージド ID での認証にあたって適切なロールを割り振る必要があるため、Storage Account に移動し、Standard Logic Apps に [ストレージ アカウント共同作成者] ロールを付与しました。
補足として、Standard Logic Apps は BLOB, Files, Queue, Table の全てのデータ ストレージにアクセスし、尚且つデータの読み書きを行うので [ストレージ アカウント共同作成者] が最小権限になります。
BLOB や Files 等の下位スコープは親スコープのアクセス権限を引き継ぐため、Storage Account 側で行うマネージド ID の設定はこれだけになります。
続いては、Standard Logic Apps リソースで作業を行います。
まず『AzureWebJobsStorage』については、変数名を『AzureWebJobsStorage__accountName』に変更して、値を Storage Account 名に変更することでマネージド ID 接続が出来るようです。
ID ベースのストレージ接続を使用する場合は、AzureWebJobsStorage で接続文字列を使用する代わりに、ストレージ アカウントのアカウント名を設定します。 この構文は AzureWebJobsStorage に固有であり、他の ID ベースの接続には使用できません。
Azure Functions のアプリケーション設定のリファレンス # AzureWebJobsStorage__accountName
こちらについては問題なく設定が行えました。
しかしながら、環境変数『WEBSITE_CONTENTAZUREFILECONNECTIONSTRING』で問題が生じます。
はじめに、当該環境変数では、リソースの負荷が高まった時に行うスケーリングのコードや構成が保存されている Storage Account の Azure Files を指定しています。
しかしながら、公式情報の内容を参考にすると、Azure Files ではマネージド ID を使用することは出来ないと記載があり、これが Storage Account にマネージド ID 接続できない原因です。
Azure Files では、ファイル共有にアクセスするときにマネージド ID を使用することはできません。
Azure Functions のアプリケーション設定のリファレンス # WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
実際、環境変数に不適切な値を入力すると「無効な値」として保存が出来ません。
以上までの内容から、Standard Logic Apps では Storage Account に接続をする際にマネージド ID を利用することは出来ないというのが結論になります。
もしかしたらの回避策
まだ試してはいないのですが、Azure Key Vault を使用することが回避策になるのではと考えています。
アクセスキーの管理には Azure Key Vault を使用し、キーのローテーションと再生成は定期的に行うことをお勧めします。 Azure Key Vault を使用すると、アプリケーションを中断することなく簡単にキーをローテーションできます。
まだ私自身 Azure Key Vault の知見が浅いので何とも言えませんが、例えば Azure Key Vault から Storage Account のアクセス キー的なのを引っ張ってきて、Standard Logic Apps の環境変数に代入出来るなら、そういったワークフローが作れれば回避策にはなるのでは？と思ってます。
もしくは、これも今更ながらボンヤリ思ったのが、最初にコネクタから Storage に OAuth で接続しておいて、アクセス キーが取得できるなら取得。からの環境変数代入なんてのは、思いました。
アクセス キーが取得できるなんていう無理のある前提の話ですけど、ワンチャン狙ってます。
ただ今回は本記事の検証だけで燃え尽きたので、また機会があったら試してみることにします。
自分での作成が難しいという方は、Twitter (こっちの呼び方がやっぱ好き) をフォローいただいて、続報お待ちいただけますと幸いです。そのうち書くかもです。