Azure認証 - ntuf/Tips GitHub Wiki

■サービスプリンシパル認証

サービスプリンシパルは、AzureADアプリケーションとして作成され
要するにAzureADに作成したアプリケーションのID・パスワードの認証を委任することができる機能

アプリケーションやサービスがAzureのリソースにアクセスするためのIDとして使用されます。

テナントやディレクトリ内に接続してくる、外部のアプリケーションを形にしたもの

サービスプリンシパルには、テナントでできることやアクセスできるユーザー、リソースが定義される

アプリケーションとサービスプリンシパルは同時に作成される

Azure ロールベースのアクセス制御 (Azure RBAC) で利用することができ、
適切にアクセス権限を付加することにより、Azure上で他のリソースにアクセスすることができるようになります。

●使用の仕方
サービスプリンシパルを作成する際に、
クライアントIDとクライアントシークレット（または証明書）が生成されます。
これらの情報を使用して、Azure ADからトークンを取得します。
取得したトークンは、Azureリソースへのアクセス認証に使用されます。

⚫️何が便利なの
アクセスキー、シークレットキーなどの認証情報を明示的にハードコードや
設定ファイルに保存する必要がないため、漏洩のリスクが減少します。
（どちらもセキュアストレージ: 資格情報は、暗号化された安全なストレージ
（例: Azure Key Vault、AWS Secrets Manager、GCP Secret Managerなど）に保存されていれば問題はない）
サービスプリンシパルやIAMロールなどは一時的なトークンを使用するため、それが漏洩しても利用期間が限定されています。
パスワードは、主に人間がサービスやアプリケーションにログインするためのものです。
対照的に、トークンベースの認証やサービスプリンシパルは、マシン間の認証やサービス間の認証に最適化されています。
トークンベースの認証は、集中管理が可能で、権限の付与や取り消し、ローテーションが容易

→　要するにトークン他の外部システムからアクセスする場合にはこれを用いるのが普通ということ

⚫️こういう認証形式って他にもあるの？
AWSであれば、IAMロールをEC2インスタンスやLambda関数などのAWSのサービスに割り当てることで、
そのサービスが他のAWSサービスやリソースにアクセスする際の認証・認可を行う
GCPでは「サービスアカウント」がこの役割を果たします。サービスアカウントは
GCP内のリソースにアクセスするアプリケーションやサービスを代表する特別なアカウントであり、
API呼び出しの認証に使用される

●他の認証方法
●マネージドID
サービスプリンシパルは外部アプリケーションが認証するために必要だったわけですが、
Azureだけでシステムが完結している場合、外部からアクセスさせる必要もありません。
その場合はよりセキュアに扱える、マネージドIDを利用するのが便利

マネージドIDを利用すると、利用者側が意識することもなく、
資格情報のローテーションや証明書の置き換えを自動的にやってくれます（つまりマネージド

システムマネージドIDは、利用するAzureリソースに直接紐づく形で、生成されるサービスプリンシパルを利用
そのAzureリソースのみからの要求を受け付けることになります。
リソースが削除されると、システムマネージドIDも一緒に削除されます。

ユーザーマネージドIDは、利用するAzureリソースに直接紐づかない形で、生成されるサービスプリンシパルを利用
そのため複数のリソースに割り当てることができ、大変便利です。
複数のリソースが同じリソースにアクセスする必要があるのであれば、こちらを利用します。

参考
https://qiita.com/hikaru_motomiya/items/a5210ed567a02a2720f4