下記のサンプル実装のインフラコード部分を解説します。
https://github.com/hirokimatsueda/azure-managed-id-sample
インフラ構成詳細
概要記事で「シンプル」と表現しましたが、構築されるリソースを明記すると若干インパクトがあるかもしれません。 しかしかなり最低限だと思いますのでどうかお付き合いを・・・。
本質的に必要なのは、中央の Functions と Cosmos DB です。
Cosmos DB の中にはデータベースやコンテナーの概念があるので、これらもインフラ構築時に作成してしまいます。
Azure のリソースは「診断設定」を設定するとリソースの状態が観測できるので、Functions と Cosmos DB に対して設定しておきます。診断ログの保管先として Log Analytics を指定しています。
Functions のアプリの状態の観測のため、Application Insights と接続しています。
Functions ではシステム割り当てマネージド ID を有効にして、Cosmos DB の権限設定でこのマネージド ID が Cosmos DB 内のデータを操作することを許可します。
terraform を用いた構築
コードはこちら: https://github.com/hirokimatsueda/azure-managed-id-sample/tree/main/infrastructure/terraform
Azure のインフラ構築には terraform を利用しています。
terraform についての説明は割愛させていただき、どのような方針で実装しているかを記載します。
module への処理の分割
terraform は、カレントディレクトリ配下(サブディレクトリを除く)の tf ファイルをすべて確認してインフラ構築をしてくれますが、リソース数が多い場合はコードの見通しが悪くなりがちです。
この時、modules という概念を使用すると処理の詳細を別フォルダに整理できるので見通しが良くなります。
マネージド ID への権限付与
下記の実装で権限付与を行っています。
azurerm_cosmosdb_sql_role_definition を使用し、Cosmos DB のデータへのアクセス権限を定義します。
これはアクセス権限の定義であり、割り当てではないです。
割り当てには azurerm_cosmosdb_sql_role_assignment を使用しています。
サンプルコードでは 2 回登場しますが、user
と名付けた方は terraform を実行した人への権限付与、data_contributor
と名付けた方は Functions への権限不要になります。
なぜ terraform を実行した人にも権限を付与しているかというと、ローカル PC でアプリの動作確認をする際に必要になるからです。
data_contributor
と名付けた方は depends_on の記載がありますが、これは azurerm_cosmosdb_sql_role_assignment を複数並列で動かすとエラーになるためです。
まとめ
terraform を用いてマネージド ID で Cosmos DB にアクセスする際のポイントを解説しました。
これさえあればインフラ構築は怖くないですね。
解説していない部分にもいろいろと小技を仕込んであるので、コード量の多さに負けずに一度見てもらえると嬉しいです。