あるチームがBicepを使って既存のAzure Key Vaultのシークレットを参照し、VMのパスワードとして使用するデプロイを行いたい。Key VaultはBicepデプロイとは別のリソースグループに既存している。このシナリオでKey Vaultのシークレット値を安全にVMの adminPassword パラメーターに渡すための正しいアプローチはどれか。
- A. Azure CLIでKey Vaultシークレットを取得してシェル変数に格納し、Bicepパラメーターとして-pフラグで渡す（シークレットがシェル履歴に残る可能性がある）
- B. Bicepファイル内でexistingキーワードを使って別リソースグループのKey Vaultリソースを参照し、getSecret()メソッドでシークレット値をsecureStringパラメーターに渡す
- C. Bicepのoutputブロックでシークレット値を出力してパイプライン経由で次のデプロイに渡す
- D. Key VaultシークレットをBicepパラメーターファイル（.bicepparam）に直接プレーンテキストで記述し、デプロイコマンドに渡す
解答と解説を見る
正解: B
BicepのexistingキーワードはAzureに既存のリソースを参照するための構文で、resource kv 'Microsoft.KeyVault/vaults@...' existing = { name: 'myKv', scope: resourceGroup('other-rg') } のように別リソースグループのKey Vaultも参照できる。その後 kv.getSecret('secretName') を使うとsecureString型のパラメーターに直接シークレット値を渡せ、シークレット値はBicepテンプレートのコードや出力には現れず安全に扱われる。選択肢DはBicepパラメーターファイルにプレーンテキストでシークレットを書くため、バージョン管理リポジトリへの漏洩リスクがある。選択肢AはCLIのシェル履歴やログにシークレットが残る可能性があり非推奨。選択肢Cはoutputにsecureオプション（@secure()デコレーター）なしにシークレットを出力するとデプロイログに平文で記録されるため厳禁であり、そもそも値の受け渡し方法として設計思想に反する。
📚 関連サービスの解説: Azure Key Vault