service principal とは？Azure の非人間アイデンティティ
service principal は Microsoft Entra ID 内のアイデンティティで、アプリケーションやパイプラインが Azure へ認証し、割り当てられた RBAC 権限で動作するために使います。
ソフトウェア（人ではなく）が Azure へアクセスする必要があるとき、それは service principal として認証します。tenant 内における Entra ID アプリケーションのローカルなインスタンスです。リソースへの RBAC role を付与し、secret、証明書、または federated credential でサインインできます。これがパイプラインが Azure へデプロイする方法です。
app registration vs service principal
app registration は Entra ID におけるアプリケーションのグローバルな定義です。service principal は特定の tenant におけるその具体的なアイデンティティであり、実際に role の割り当てを受け、サインインするものです。実務上、app registration を作成すると service principal が作成されます。
認証の方法
- client secret（パスワード、最も好ましくない）。
- 証明書。
- federated credential（OIDC）。CI 向けの鍵なしの選択肢。
RBAC 権限
service principal には、subscription、resource group、個々のリソースにスコープした Azure RBAC role を割り当てます。最小権限が適用されます。デプロイ用の principal は、必要なリソースだけを更新できるべきで、それ以上は不要です。
代替としての managed identity
Azure 内で実行される workload では、managed identity は Azure が代わりに管理する service principal であり、扱うべき認証情報がありません。外部 CI では、代わりに federated credential を持つ service principal を使います。
CI/CD での役割
パイプラインは service principal として認証してデプロイします。GitHub Actions からの現代的で鍵なしの方法は federated credential（OIDC）です。workflow が GitHub トークンを提示すると、Entra ID がそれを信頼し、client secret なしでアクセスを発行します。federation は特定の repo と branch にスコープしましょう。
重要なポイント
- service principal は、アプリやパイプラインが認証に使う Azure のアイデンティティです。
- secret、証明書、または鍵なしの federated credential（OIDC）を使えます。
- パイプラインは、理想的には federation 経由で、最小権限の service principal としてデプロイします。