Azure Service principal

Azureサービスプリンシパルとは
1. サービスプリンシパルの用途
Azureサービスプリンシパルの作成と権限付与
簡単なサンプル(Powershell)
最後に
その他の参考サイト

Azureサービスプリンシパルとは

サービスプリンシパルは、リソース/サービスレベルの無人操作を実行する目的でテナント内で作成する Azure Active Directory アプリケーションリソースです。アプリケーション ID とパスワードまたは証明書が与えられた、独自のユーザー ID です。サービスプリンシパルには、割り当てられたロールとアクセス許可によって定義されるタスクを実行するために必要な権限のみが与えられます。
From Document

Azure サービスプリンシパルは、簡単にいうとアプリやサービスに権限を付与するためのAzureアカウント(プロキシアカウント/ID)です。
Azure AD のユーザーアカウントと同じく、Azure AD に管理されています。(テナントレベルに存在する)

多くの場合、アプリ(スクリプトなども)から Azure のリソースへアクセスする時に、Azure リソースへの権限が必要となります。
アプリ用の Azure AD ユーザーを用意して、アプリ内や設定ファイルにユーザー名とパスワードを入れてもアクセスできますが、ユーザー&パスワードの漏洩が発生するリスクや、アカウント更新するときに手間が発生するなどのデメリットがあります。
サービスプリンシパルを使用することで、これらのデメリットがすべて解消できます。

※ 2022/10/24：サービスプリンシパルの場合、アカウントの期限は最大（Azure ポータルで設定する場合）2 年となりますので、更新は必要になります。

~~※もしGCPに経験を持つ方でしたら、AzureサービスプリンシパルはGCPのサービスアカウントと似たようなものと理解して無難であろう。~~
2021/01/18追記：
もし多少開発の知識をお持ちであれば、サービスプリンシパルの本質をこちらのドキュメントで理解できるかと思いますが、ただし仕組みを理解するには、そこまで深堀しなくても問題ないと思います。
気になる方は以下抜粋を貼っておきます。

サービスプリンシパルは、アプリケーションオブジェクトから作成された具象インスタンスであり、そのアプリケーションオブジェクトから特定のプロパティが継承されます。

サービスプリンシパルの用途

2021/01/18追記：
サービスプリンシパル実は、代理(プロキシ)のアカウントです。
サービスプリンシパルと同じテナントのアプリケーションだけではなく、オンプレミスや他のテナントのアプリケーションを代理し、認証することも可能です。

公式資料の図を使わせていただくと、こんな感じです。

この特徴によって、以下の場合で、サービスプリンシパルが使用されることが多いです。

アプリケーションまたはサービスがオンプレミス/他のクラウド/他の AzureAD テナントで実行されている場合、Azure への認証認可
アクセスする必要があるリソースまたはアプリケーションで、マネージド ID がサポートされていない場合、Azure への認証認可

※マネージド ID は簡単に言うと、Azure ~~のリソース~~で管理されるリソースに紐づけるアカウントと考えるといいです（※Arc も対象）。今後にさらに詳しく説明する予定です。
※マネージド ID は、サービスプリンシパルよりも安全かつ便利です。可能であれば、マネージド ID を使用することを推奨します。

Azureサービスプリンシパルの作成と権限付与

さて、Azureサービスプリンシパルの作成と設定を紹介していきます。
※もし環境をお持ちであれば、環境の設定箇所を参照しながら見たほうが、イメージ湧きやすいかと思います。

公式ドキュメントにも詳細な手順があるので、ご参考いただければと思います。

サービスプリンシパルの作成

~~Azureサービスプリンシパルは Azure の以下のところで作成可能です。~~：2021/01/18
2021/01/18追記： Azure portal を使用してサービスプリンシパルを直接作成することはできません。 Azure portal 経由でアプリケーションを登録するときに、アプリケーションオブジェクトとサービスプリンシパルは自動的にホームディレクトリまたはテナントに作成されます。

「Azure Portal」->「Azure Active Directory」->「アプリの登録」->「新規登録」

作成時、以下のパラメータがあります。

名前：サービスプリンシパルの表示名(後で変更可能)
アカウントの種類の指定：(2021/01/18追記：アプリケーションを使用できるユーザーを決める)
- この組織ディレクトリ(AAD)のみに含まれるアカウント：シングルテナントの場合に使用する
- 任意の組織ディレクトリ(AAD)内のアカウント：マルチテナントの場合使用する
- 個人のMicrosoftアカウント(Skype、Xboxなど)：個人アカウントでアクセスの場合に使用する
リダイレクト URI(省略可)：認証を他のところにリダイレクトする設定(認証は他のところでする)
- 2021/01/18追記：アクセストークンの送信先の URI

アプリの登録について

2021/01/18追記：
上記の通り、「アプリの登録」でアプリケーションのオブジェクトとサービスプリンシパルのオブジェクトが作成されます。
アプリケーションが作成されたと同時に、アプリ(またはクライアント) ID が割り当てられます。
アプリケーションオブジェクトは、アプリケーションの登録先である Azure AD テナント (アプリケーションの "ホーム" テナントと呼ばれます) 内にあります。1 つ以上のサービスプリンシパルオブジェクトを作成するためのテンプレートまたはブループリントとして使用されます。

サービスプリンシパルの権限割り当て

権限割り当ての部分について、普通のAzureADユーザーの権限付与と同じで、RBACを使って設定します。
設定箇所は以下となります。

「リソース」->「アクセス制御(IAM)」->「＋追加」->「ロールの割り当てを追加する」

「リソース」については、「サブスクリプション」で設定すると、サブスクリプションレベルの権限になるし、「リソースグループ」で設定すると、リソースグループレベルのお権限になります。もちろん指定のリソースのところで設定すれば、そのリソースへのみの権限になります。

サービスプリンシパルのアクセスキーの発行

サービスプリンシパルでAzureｎリソースにアクセスするには、以下の情報が必要です。

テナント(ディレクトリ)ID：Azure ADテナントを識別する一意のID
アプリケーション(クライアント)ID：Azure ADアプリケーション(サービスプリンシパル)を識別する一意のID
資格情報(2種類のどちらでもいい)：
- クライアントシークレット：Azureが生成される長い文字列。アプリケーションのパスワードとして使用する
  - キーの有効期限指定可能：1年/2年/なし
  - 有効期限設定でセキュリティ向上できますが、切れた場合アクセスできなくなるため、管理が必要になる。
- 証明書アップロード(公開キー)

簡単なサンプル(Powershell)

上記の手順で、サービスプリンシパルが使用できるような状態になります。

2021/01/18追記：
また、Azure ADアプリケーションで認証するために、カスタムアプリ以下の情報が必要です。

テナントID
アプリケーションID(クライアントID)
認証キー(クライアントシークレット文字列)

簡単にPowershellのサンプルで、Azureサービスプリンシパルの使用例をお見せしようと思います。
※コメント付きでサンプルコードを書きます。

# Powershell

# 変数で必要な情報を用意する
$tenantId = "<テナントID>"
$appId = "<サービス プリンシパルのアプリID>"
$secretKey = ConvertTo-SecureString "<クライアントシークレット文字列>" -AsPlainText -Force  # 文字列をパスワードとして使用する場合、セキュア文字列に変換する必要がある

# 認証用PSオブジェクトを作成する。
# $credentials = Get-Credential  # こちら(ユーザー&パスワード入力)でオブジェクトを作成する場合、パスワードは平文の<クライアントシークレット文字列>を使う。

$credentials = New-Object System.Management.Automation.PSCredential -ArgumentList ($appId,$secretKey)

# ログイン
Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant $tenantId

az-login と Connect-AzAccount どちらでも Powershell で実行できるが、それぞれの認証情報は分かれているので、間違わないように