Azureの鬼門、サービス プリンシパル
おはこんばんちは！コンテナソリューショングループの髙井です。
Azureをやっていく過程で誰しも必ず引っかかるのがサービス プリンシパルだと思います。
なんで引っかかるかというと、Azureには同じロールという言葉で、ディレクトリ ロールとリソース ロールの2種類が存在するからです。
ディレクトリ ロールはAzure Active Directory由来のロールで、リソース ロールはARM由来のロールになっています。
それでもってサービス プリンシパルは、この2種類のロールの両方に絡むんですね。なるほど難しくもなるわけです。
チームで共有する場合はもっと難しい
ただでさえ難しいサービス プリンシパルですが、チームで利用しようとするとさらに難しくなります。
というのも個人単位で使用する場合は、使うサービス プリンシパルを自分が作成しているケースがほとんどで、その場合はディレクトリ ロールが所有者になるので権限が足りなくなることが発生しにくいからです。
一方で、チームで利用する場合、作る人と更新する人が一致していなかったりして権限まわりのエラーが出やすくなります。
さらに理解を難しくするAADアプリケーション
サービス プリンシパルを作ろうとすると、次に立ちはだかるのが「アプリ」という概念です。
ロールと聞いたときに普通イメージするのが、誰が何をできるかだと思います。つまり、「ユーザー」に対して権限を付与するというイメージです。
そうではなくて、権限をもったオブジェクトを生成するのが、Azure PortalのAzure Active Directory画面上にある「アプリの登録」なのです。
このあたりの話は、Azureの利用料金をSlackに通知させる【前編】の記事でも書いています。
しかも、Portal上では「アプリの登録」と名前がついていますが、Azure CLIでは以下のようにコマンドがサービス プリンシパル（sp）となっており名前が一致していないため、さらなる混乱を招きます。
az ad sp create-for-rbac -n "MyApp" --role Contributor --sdk-auth
厳密に言うとアプリとサービス プリンシパルはイコールではないのですが、最初のうちは同じものだと捉えてしまってもいいかもしれません。
チームでサービス プリンシパルを使うときに押さえるべきポイント
以上のように、個人で使うにも初見ではかなり難しいサービス プリンシパルですが、チーム利用の際にはさらに押さえておくべきポイントがあります。
他の人が作ったサービス プリンシパルはデフォルトでは更新できない
たとえば、AKSクラスターにAGIC（Application Gateway Ingress Controller）をインストールするにはサービス プリンシパルに関するシークレット情報が必要です。
シークレット情報は作成時にしか手に入らないため、クラスターごとに固定のサービス プリンシパルを使おうとすると、AGICを再インストールしたい場合などにサービス プリンシパルを上書き作成する形になります。
このとき、作った人以外は上書き更新できません。考えてみれば当然で、自分が作成したサービス プリンシパルを他の人に勝手にバンバン書き換えられたら困りますよね。
そのため、他の人が上書き更新できるようにするためには、その人をアプリの所有者にしてあげる必要があります。
アプリの所有者にグループは指定できない
所有者にすればいいのであれば、チームメンバーが属するAADグループに所有者ロールを割り当てたくなりますが、これはできません。
そのため、対象の人を1人ずつ割り当ててあげる必要があります。ただし、1つのアプリの所有者になれるユーザーは最大で100名です。
サービスプリンシパルを使い捨てる
あるいは、更新せずに毎回新しいサービス プリンシパルを作ってしまう手もあります。
ただ、その場合は古いサービス プリンシパルのゴミがたまるので削除するのを忘れないようにしてください。
自分が所有者のアプリは以下のコマンドで確認できます。
az ad sp list --show-mine -o tsv --query [].displayName
おわりに
サービス プリンシパルの複数人利用について簡単に紹介しましたが、ロールまわりの登場人物には今回紹介していないマネージド IDなどもいたりします。
ちゃんと理解しようと思うと範囲が膨大ですが、少しずつこちらのブログでも紹介したいと目論んでいる最中です……！乞うご期待。
それではあなたのAzureライフが楽しくなるように、Stay Azure！
