kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure PipelineのパイプラインでLibraryを勝手に使われたくない場合にするセキュリティ設定

ascii.jp

業務で使う場合は、GitHubのPersonal Access Tokenをどう扱うかは気を付ける必要があります。Libraryに保存しちゃうと意図しないPipelineで使われてしまうリスクがあるので、どうすると良いですかね?

という疑問が末尾に書かれていたので、どうするのがいいか考えてみましょう。まず、大前提として、GitHubのPATをLibraryに格納する場合、GitHubのPATにアクセスできる人だけをAdministratorにしておきます。

f:id:kkamegawa:20201014194824p:plain

PAT単位にセキュリティを設定する場合はPATを作ったユーザーのみadministratorにします。デフォルトはLibraryからの継承なので、都合が悪い場合は継承を切ってください。ただし、Build Serviceアカウントを削除してしまうとビルドエージェントがLibraryを参照できなくなるので気を付けてください。

f:id:kkamegawa:20201014194305p:plain

Libraryのセキュリティでも設定できます。通常はLibraryを管理するユーザーを決めておきましょう。Build AdministratorかProject Administratorのみ管理者なので大体大丈夫のはずです。

f:id:kkamegawa:20201014194319p:plain

記事内で心配されていた「知らないpipelineに使われる」というのはservice connectionの権限で防ぎます。https://dev.azure.com/{organization}/{project}/_settings/adminservices画面でGitHubのへの接続を作っています。

f:id:kkamegawa:20201014203232p:plain

Approvers and ChecksはEnvironmentと同じ設定ができます。典型的にはBusiness Hourだけ使えるようにするとかそういった制御ができます。

docs.microsoft.com

下のSecurityをクリックすると、画面の真ん中にPipeline permissionがあるので、そこでGitHubへの接続を使えるパイプラインを明示的に指定します。

f:id:kkamegawa:20201014203559p:plain

これで仮にLibraryの値を意図しないパイプラインで参照されたとしても、GitHubへのアクセスができなくなります。

いちいちプロジェクトごとにそんな設定するのめんどいなぁ、という場合、その下にあるProject Permissionからこのservice connectionが使用可能なプロジェクトを指定します。

f:id:kkamegawa:20201014203747p:plain

ここで指定されたプロジェクトはこのGitHubへの接続が使用可能になります。大きなプロジェクトではチームプロジェクト単位でservice connectionを作るのではなく、特定のプロジェクトに集中させて、ほかではこういった外部接続を使わないようにすれば集中管理が可能になります。