Microsoftは、Azure DevOpsのパイプラインが他のリポジトリやArtifacts feed、REST APIにアクセスする際の認証方式として、新しい「Azure DevOps service connection」を発表した。これまでPersonal Access Token(PAT)やビルドセッショントークンで行っていた認証を、Microsoft EntraのワークロードID(サービスプリンシパルまたはマネージドID)に置き換えられる。
PATが抱えていた課題
Azure DevOpsのパイプラインが外部リソースにアクセスする従来の主な手段はPATだった。PATは長期間有効な文字列シークレットで、発行したユーザーの権限をそのまま引き継ぐケースが多く、発行・保管・定期ローテーション・失効管理をすべて人手で行う必要があった。ビルドサービスアカウントの権限を使う運用も同様で、パイプライン単位・タスク単位の最小権限とは相性が悪い。漏洩すれば発行者の権限範囲でAzure DevOpsに広くアクセスされてしまうリスクも常につきまとっていた。
Service Connectionの仕組み
新しいService Connectionは、Entra IDのフェデレーション資格情報(Federated Credential)を使って認証する。パスワードや秘密鍵といった永続的なシークレットをどこにも保存せず、Entra ID側で発行される短命なトークンでAzure DevOpsにアクセスする点が最大の特徴だ。認証試行はすべてAzure DevOpsの監査ログに記録されるため、追跡可能性も高まる。Entra IDのアイデンティティとして認証するので、同じEntra IDテナントに参加していれば、自組織だけでなく別のAzure DevOps組織のリソースにもこの接続でアクセスできる。
設定の流れ
利用にはまず、サービスプリンシパルまたはマネージドIDをAzure DevOps組織のユーザーとして追加し、必要な権限(例:対象プロジェクトのReadersグループへの追加)を事前に割り当てておく必要がある。そのうえで新規サービス接続の作成画面から「Azure DevOps (preview)」を選び、用意したIDを指定する。利用者がMicrosoft Graphの権限を持たずフェデレーション資格情報を自動作成できない環境では、発行者(issuer)とサブジェクト(subject)の情報が画面に表示され、権限を持つ管理者が手動でEntra ID側に資格情報を追加するフォールバック手順が用意されている。
パイプラインでの使い方
設定したService Connectionは、YAMLパイプラインのresources.repositoriesで外部リポジトリをcheckoutする用途や、別組織のYAMLテンプレートをtemplateで参照する用途に使える。ランタイムパラメータでService Connection名を渡せるため、呼び出し側が接続先を切り替えられるテンプレートも組める。ほかにもNuGetAuthenticateタスクでのArtifacts feed認証や、InvokeRESTAPIタスクからAzure DevOps REST APIを直接呼び出す用途にも対応している。
実務への影響
日本のIT現場でも、複数のパイプラインで同じPATを使い回している、あるいはビルドサービスアカウントに広い権限を与えたままにしている構成は珍しくない。特に事業部や子会社ごとにAzure DevOps組織を分けている企業では、組織をまたぐリポジトリ参照やテンプレート共有のためにPATが飛び交いがちで、このService Connectionはそうした構成に直接効いてくる。
常時有効なシークレットを廃止し、フェデレーション資格情報による認証に置き換えるという方向性は、特権アクセスをJust-In-Timeで最小限に絞るゼロトラストの考え方と軌を一にしている。「今動いているから大丈夫」で放置されたPATは、担当者の異動や退職後も生き続けて監査対象から漏れやすい。既存PATの棚卸しやローテーションのタイミングは、この新方式への切り替えを検討する好機になる。
現時点ではプレビュー機能であり、対応済みのタスクはNuGetAuthenticateやInvokeRESTAPIなど一部にとどまる。全パイプラインを一度に移行するのではなく、まずは外部依存の強いテンプレート共有やArtifacts feedアクセスなど、影響範囲が明確な箇所から段階的に置き換えていく進め方が現実的だろう。
出典: この記事は You can now use the Azure DevOps Service Connection instead of a PAT or Build Session token の内容をもとに、筆者の見解を加えて独自に執筆したものです。