Azureを実務で触っていて、 一番時間を溶かしたのは「権限」でした。
Terraformでもない。 ネットワークでもない。
RBACです。
Azureって、 最初は「クラウドのインフラサービス」に見えるんですが、 実際に深く触っていくと、
「組織と権限を設計する世界」
だと気づきます。
特に、
- Managed Identity
- RBAC
- Key Vault
- ACR
- サブスクリプション境界
- テナント
この辺が絡み始めると、 一気に難易度が跳ね上がる。
今回は、 実際に私がハマった
「Terraform applyは成功するのに、実行時だけ403になる」
問題について書いてみます。
「構築は成功している」のに動かない
今回ハマった構成は、 ざっくり言うとこんな感じでした。
Logic Apps ↓ ACI（Azure Container Instances） ↓ ACR（Azure Container Registry）
Logic AppsからACIを起動し、 ACIがACRからコンテナイメージをPullする。
構成自体はよくある形です。
Terraform apply も成功。
Managed Identity も設定済み。
AcrPull ロールも付与済み。
でも動かない。
ACI側ログを見ると、 出てくるのは無慈悲な403。
Code: InaccessibleImage Message: The image could not be accessed
最初は単純に、
「AcrPull付け忘れかな？」
くらいに思っていました。
でも、そこから3日溶けました。
Azureの403は「設定ミス探し」では終わらない
Azureの難しいところって、
「設定した」だけでは終わらない
ところなんですよね。
例えば今回も、
- RBAC設定済み
- Managed Identity有効
- Terraform成功
- ACR存在確認OK
ここまでは全部通っていました。
でも実際には、
- 実行主体は誰か
- Tokenが反映されているか
- どのスコープへRBACを付けたか
- System AssignedかUser Assignedか
- ARM権限なのかData Plane権限なのか
みたいな話が全部絡んでくる。
特にAzureって、
「作成権限」と「実行権限」が別世界
だったりするんですよね。
Terraform apply が成功している時点で、 ARM側の権限は通っている。
でも実行時に必要なのは、 ACIが実際にACRへアクセスするための権限。
つまり、
「実行時の主体」
を正しく理解していないと、 永遠に403が消えない。
結局、今回の原因は、
「ACIがACRからイメージをPullする際の認証主体」
の取り違えでした。
最初は、
Managed Identity を有効にした ↓ AcrPull を付与した ↓ だから動くはず
と思っていた。
でも実際には、 「ACI内部で動くアプリのIdentity」と、 「ACIリソース自体がACRへアクセスするIdentity」は別の話だったんですよね。
つまり、
「誰が、どのタイミングで、どの権限を使うのか」
まで理解していないと、 Azureの403は解決できない。
ここがかなり難しかった。
一番怖いのは「全部合ってるように見える」こと
Azureの権限周りで怖いのは、 エラーそのものじゃありません。
むしろ怖いのは、
「全部正しく設定したように見える」
こと。
Portalを開く。
Role Assignment を見る。
確かに AcrPull は付いている。
Managed Identity も有効。
でも動かない。
この状態、 本当にメンタルが削られます。
深夜、 ACIログを見ながら、
「もう本当に何が足りないんだ……」
となっていました。
しかもAzureって、 RBAC反映に少し時間差があるケースもある。
だから、
- 本当に設定ミスなのか
- まだ反映されていないだけなのか
の判断も難しい。
Terraform apply は成功しているのに、 実行時だけ失敗する。
この“見えづらさ”が、 Azureの403をかなり厄介にしていると思います。
Managed Identityを理解すると「Azureの見え方」が変わる
今回かなり感じたのは、
Managed Identityを理解すると、Azureの見え方が変わる
ということでした。
最初は単純に、
サービスに権限を付ける仕組み
くらいに思っていた。
でも実際には違う。
Managed Identityって、 Azure世界における
「誰が、何へ、どの権限でアクセスするか」
そのものなんですよね。
だから、
- Key Vault参照
- Storageアクセス
- ACR Pull
- SQL接続
全部ここへ繋がってくる。
つまりAzure実務って、 インフラ構築というより、
「権限設計」
なんだと思いました。
TerraformとAzureを組み合わせると難易度が跳ねる
Terraform単体なら、 まだ分かりやすい。
Azure単体でも、 Portal操作ならなんとかなる。
でも：
Terraform × Azure RBAC × Managed Identity
になると、 急に難しくなる。
なぜなら、
「コード上では正しい」
のに、
「実行時だけ失敗する」
世界になるから。
しかもTerraform側ではエラーにならない。
apply成功。
planも綺麗。
でも動かない。
これ、 かなり怖いです。
実際、 一時期 Azure の403を見るだけで、 少し胃が痛くなっていました。
「403と戦った経験」は市場価値になる
正直、 RBACやManaged Identityって、 かなり地味です。
Terraformみたいに 「IaCやってます！」 ほど派手ではない。
でも実務では、 むしろこの辺が本番だったりする。
実際、エージェント案件を見ていても、
- Entra ID
- RBAC
- Azure運用設計
- Key Vault
- Managed Identity
辺りを触れる人って、 意外と少ない印象があります。
だからこそ、
「403を解決できる人」
って強い。
以前書いた Terraform import地獄の記事でも触れましたが、
実務で市場価値になるのって、 綺麗な成功体験だけじゃないんですよね。
むしろ、
- ハマった
- 壊した
- 復旧した
- 原因を追った
みたいな泥臭い経験の方が、 あとから効いてくる。
特にAzureは、 “運用でハマった経験” そのものが価値になる世界だと思っています。
Azureは「クラウド」ではなく「組織」を扱う
Azureを触り始めた頃は、
- VM
- App Service
- Storage
- Functions
みたいな“サービス”ばかり見ていました。
でも実務で深く触るほど、 Azureって結局、
「誰が何へアクセスできるか」
を設計する世界なんだと感じます。
つまり、
「組織と権限の設計」
なんですよね。
なぜAzureがここまで権限に厳しいのか。
それは、 多くの企業が Entra ID（旧Azure AD） を基盤に、
- 数千人規模の社員権限
- 全社セキュリティ
- 監査ログ
- ガバナンス
- ゼロトラスト
を統合管理しているからだと思っています。
つまりAzureって、 単なるクラウドサービスではなく、
「企業そのものを管理する基盤」
なんですよね。
だからこそ、
- RBAC
- Managed Identity
- Key Vault
- Conditional Access
辺りの理解は、 エンタープライズ領域ではかなり市場価値へ直結する。
最近はそう感じています。
最後に：Azure実務は「権限」と向き合う仕事だった
Azureを深く触る前は、
- App Service
- Functions
- Container
- IaC
みたいな技術要素ばかり見ていました。
でも実際に運用へ入ると、 最後は結局、
「誰が、何を、どこまで出来るか」
へ戻ってくる。
深夜、 403ログを見ながら、
「権限ってこんなに難しいのか……」
と何度も思いました。
ただ、その泥臭い経験ほど、 あとから効いてくる。
Terraform import地獄の記事でも書きましたが、 実務で本当に市場価値になるのは、
「綺麗に作れた経験」
より、
「壊れたものを理解して直した経験」
なんじゃないかと思っています。
最近はそう感じています。
あわせて読みたい
- Terraform import地獄を突破する実践戦略。既存Azure環境をコード化して分かった「本当の難所」
- Azureエンジニアが市場価値を「デバッグ」する。Terraform経験を単価に変える生存戦略
- なぜ今Terraformなのか？実務運用で感じた「コード化」の真価
- インフラエンジニアが「運用だけ」から抜け出して単価が変わった話
