タイトルの通りですが、セキュリティ保護のためネットワーク制限をしたストレージアカウントを使用して Azure Functions (Function App) を「新規」に展開する場合の注意点として気づいた内容となります。
Contents
今回の事象に気づいた経緯
最初に、今回の事象に気づいた経緯について記載しておきたいと思います。
Azure Functions を使用していて、当初はネットワーク制限をされていないストレージアカウントを使用していたのですが、ストレージアカウントの要件としてネットワーク制限が必要となったため、「すでに展開している Function App」に対して、ネットワーク制限をされたストレージアカウント に必要となる設定を行っていきました。
本構成で必要な作業としては次のような内容となります。
- Azure Functions で 仮想ネットワークの統合 の設定を追加
- ストレージアカウントに サービスエンドポイントを使用した Azure Functions を統合したサブネットからのアクセス を許可
Function App の展開は Bicep で実施しており、当初から仮想ネットワークの統合は実施していました。
そのため、ストレージアカウントを展開している Bicep に対して、Functions のサブネットからのアクセスのみを許可する設定を追加し、Bicep を再適用することで設定を追加し、期待した動作となることを確認していました。
つまり「展開済みの Functions / ストレージアカウントに対して設定を追加」した状態となっていました。
新しく環境を構築するため、ここで使用していた Bicep を再利用して新しいリソースで環境の展開を実施したところ「Azure Functions が展開後にエラーとなってしまいリソースを正常に起動することができない」状態が発生していました。
Application Insights のログを見ると、「home\site\wwwroot」へのアクセスができず、Functions を正常に起動することができないログが記録されていました。
使用しているストレージアカウントを見ると確かに Azure Files 上に共有は作成されていない状態となっていました。
ただし、設定としては「展開済みの Functions / ストレージアカウントに対して設定を追加した環境」と、「新規に Functions / ストレージアカウントを展開した環境」とは設定の差はないという状態でした。
事象が発生していた原因
この原因ですが、次の記事とドキュメントに記載されている事象が原因でした。
Bicep で新規に展開した際にはエラーは発生せずに正常に完了していたため、Portal から手動で作成をしてみたところ「1.」の事象が発生し、これらの挙動についての情報を確認することができました。
Bicep のサンプルについては こちら で公開されていますが、Bicep でネットワーク制限されたストレージアカウントで新規に展開を実施する場合、Functions で使用する Azure Files は明示的に手動で作成をしておく必要があることが原因でした。
明示的に作成をしておらず、「WEBSITE_CONTENTSHARE」に指定した Azure Files の共有が存在していなくても Bicep による展開は正常に完了したというステータスとなり、リソースは展開された状態となります。(Azure Portal で手動で作成した場合はエラーとなり、リソースを作成する段階で止まります)
しかし、指定している共有が存在しないため、Functions のリソースをポータルで開くとエラーとなり動作しないという状態となります。
「展開済みの Functions / ストレージアカウントに対して設定を追加した環境」では、ネットワーク制限していない段階のストレージアカウントで Functions の展開を実施しており、展開後にネットワーク制限を実施しため、共有は作成済みの状態となっていました。(ネットワーク制限していないストレージアカウントのため自動で作成される)
しかし、新規に展開した環境では新しいストレージアカウントを使用しており、共有は存在しない状態となっていたので、展開後にエラーとなっていたというのが今回の顛末でした。
Functions を展開している Bicep に次のような Files の共有を作成する定義を追加したところ、正常に動作するようになりました。
resource fileService 'Microsoft.Storage/storageAccounts/fileServices/shares@2022-05-01' = { name: '${functionStorageAccountName}/default/${functionContentShareName}' dependsOn: [ storageAccount ] }
設定変更は Bicep を再適用することで実施していたため、新規展開時にも問題はないだろうと安易に考えてしまっていたのですが「作成した Bicep が新規展開時にも期待した環境となっているか」についは考慮をしておかないといけませんね。(これはコードベースの展開に限らず、手動で設定を変更して環境を整備した際にも同様ですが)