Microsoft Entra ID のアプリ登録と認証方式
Azure のリソースを GitHub Actions など外部サービスから操作する場合、Microsoft Entra ID のアプリ登録を利用する。
アプリ登録を行うと、主に以下の ID が発行される。
Application (client) ID
Directory (tenant) ID
Application (client) ID はアプリを識別する ID、Directory (tenant) ID は所属する Entra ID テナントを識別する ID である。
サービスプリンシパル
アプリ登録はアプリの定義であり、Azure 上で実際に権限を持って動作する主体がサービスプリンシパルである。
たとえば Azure Storage に書き込ませる場合、サービスプリンシパルに Storage Blob Data Contributor などの RBAC ロールを付与する。
App Registration
↓
Service Principal
↓
Azure RBAC
↓
Azure Storage
クライアントシークレット
クライアントシークレットは、アプリ用の固定パスワードのような認証情報である。
GitHub Actions
↓
Client ID + Client Secret
↓
Microsoft Entra ID
↓
Access Token
仕組みは単純だが、シークレットを GitHub Secrets などに保存する必要がある。また、有効期限があるため更新管理も必要である。
フェデレーション資格情報
フェデレーション資格情報は、外部の IdP が発行したトークンを Microsoft Entra ID が信頼する仕組みである。
GitHub Actions の場合は OIDC を利用する。
GitHub Actions
↓
OIDC Token
↓
Microsoft Entra ID
↓
Federated Credential と照合
↓
Access Token
Azure 側では、対象となる GitHub Organization、Repository、Branch などを登録する。
これにより、Azure 用の固定シークレットを GitHub に保存する必要がなくなる。
OIDC と OAuth 2.0
今回の構成では、OIDC は主に認証、OAuth 2.0 の Access Token は Azure API へのアクセスに利用される。
GitHub Actions
↓
OIDC Token
↓
Microsoft Entra ID で認証
↓
OAuth 2.0 Access Token
↓
Azure API
OIDC トークンと Azure の Access Token は別物である。
クライアントシークレットとの比較
| 項目 | クライアントシークレット | フェデレーション資格情報 |
|---|---|---|
| 認証方法 | 固定シークレット | OIDC |
| 秘密情報の保存 | 必要 | 不要 |
| 有効期限管理 | 必要 | 固定シークレットなし |
| GitHub Actions との相性 | 利用可能 | 適している |
GitHub Actions から Azure に接続する場合は、長期的な秘密情報を保持しなくてよいフェデレーション資格情報が扱いやすい。
認証と認可は別である
フェデレーション資格情報は「誰であるか」を確認する認証の仕組みである。
一方、Azure Storage に書き込めるかどうかは Azure RBAC によって決まる。
OIDC
↓
Microsoft Entra ID
↓
認証
↓
Azure RBAC
↓
認可
↓
Azure Storage
そのため、GitHub Actions から Blob Storage に書き込む場合は、サービスプリンシパルに Storage Blob Data Contributor などの権限を付与する必要がある。
まとめ
GitHub Actions から Azure へ接続する場合、以下の構成となる。
GitHub Actions
↓
OIDC
↓
Microsoft Entra ID
↓
Federated Credential
↓
OAuth 2.0 Access Token
↓
Azure RBAC
↓
Azure Resource
クライアントシークレットは固定パスワード方式、フェデレーション資格情報は外部 IdP との信頼関係を使う方式である。
GitHub Actions では、固定シークレットを持たずに認証できるフェデレーション資格情報を利用する構成が適している。