Azure Artifactsに関してこんな相談を受けました。
Azure DevOps で別Project で作ったArtifacts の Private Feed のパッケージが Azure Pipelines のNuGet でリストアできない…
— 伊右衛門 (@IYEMON018) 2020年2月14日
返信で回答しており、できたということなんですが、一応備忘録的に書いておきます。
まず、Azure Artifactsには全世界に見えるPublic、Organization、Projectといった三段階のスコープがあります。やったことはないですが、Publicにしても例えばAzure の条件付きアクセスポリシーを設定してしまえば、「社員(事務所など)からはみえるんだけど、一般の人には見えない」なんてArtifactsフィードもできるのかな。これできたらちょっと便利なケースがありそうですが。条件付きアクセスポリシーの対象外になるのかなーどうかなー。
Active FeedsとDeleted Feedsの二種類があります。さらにProject(Testfeed)とOrganization(internal_pre_publishとlocalMaven)レベルですね。
Deleted Feedsに切り替えるとゴミ箱に入れたフィードが表示されます(入れてないので空です)。さて、このProjectのフィード(TestFeed)はよそのチームプロジェクトからは参照できません。しかし、昔はArtifactsのスコープがProjectしかなかったので、その経緯でProjectのままになっているとか、あとから見せたくなったとか、理由で参照させたいことはあります。
そういうときはClassicの場合、ビルド定義でBuild job authorization scopeをProject Collectionにしてください。Collectionってなんやねん、と思われるかもしれませんが、現在のOrganizationのことです。Organizationという名前があとからできてしまったので、整合が取れて無いですね…。Azure DevOps Server 2019ではCollectionでいいのですが。
え、おれのビルド定義もうYAMLしか書いてないけど、そんなのないよ？どうやるの？という方もいると思います。
そういう場合、ProjectのPipelinesのSettingsにあるLimit job authorization scope to current projectを設定します。有効にするとジョブは現在のプロジェクトのみです。スクリーンキャプチャはOrganizationレベルの設定なので、こちらを設定すると全プロジェクトはプロジェクト外のリソースにはアクセスできなくなります。
この設定はビルド管理者の権限が必要になるのと、有効にしてしまうとほかのプロジェクトのリソースに簡単に参照できるようになるので、気を付けてください。
過去のフィードは致し方ないのですが、Artifactsは基本的にOrganizationレベルで作ることをお勧めします。ここが一番大きなセキュリティの分界点です(というお話をIgnite The Tourでもさせていただきました)。
