説明
Function App が他の Azure リソースに接続するための接続文字列やアクセスキーを直接管理すると、漏えいや交換漏れのリスクが生じます。マネージド ID を使うと、対応するサービスに個別のアプリケーションシークレットなしで認証できます。マネージド ID がないだけで、シークレットの使用や漏えいが確認されたわけではありません。
想定される影響
- コードや設定に保管した認証情報が漏えいするおそれがあります。
- 認証情報の交換や失効が漏れる場合があります。
- 関数ごとのアクセス権限を管理する負担が増える場合があります。
対処方法
対応する接続では identity ブロックで適切な SystemAssigned または UserAssigned ID を構成してください。接続先に必要な権限だけを付与し、関数が実際にマネージド ID のトークンを使うように設定してください。動作確認後、置き換えたシークレットを削除して失効させてください。
例
AzureRM 3.x の旧 azurerm_function_app にシステム割り当てマネージド ID を追加する例です。必須のストレージ設定、接続先の権限、トークンを使うコードは省略しています。
変更前
hcl
resource "azurerm_function_app" "example" {
name = "test-azure-functions"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
app_service_plan_id = azurerm_app_service_plan.example.id
}
変更後
hcl
resource "azurerm_function_app" "example" {
name = "test-azure-functions"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
app_service_plan_id = azurerm_app_service_plan.example.id
identity {
type = "SystemAssigned"
}
}
変更後は SystemAssigned ID が関連付けられます。それだけで接続先の権限が付与されたり、既存の接続文字列が自動的に置き換わったりするわけではありません。マネージド ID は、関数を呼び出すユーザーの認証とも別です。