リポジトリ、成果物、その他のリソースにアクセスする

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

実行時に、パイプライン内の各ジョブが Azure DevOps 内の他のリソースにアクセスする場合があります。 たとえば、ジョブでは次の場合があります。

• Git リポジトリからソース コードをチェックアウトする
• リポジトリにタグを追加する
• Azure Artifacts のフィードにアクセスする
• エージェントからサービスにログをアップロードする
• エージェントからサービスにテスト結果やその他の成果物をアップロードする
• 作業項目を更新する

Azure Pipelines では、ジョブ アクセス トークンを使用してこれらのタスクを実行します。 ジョブ アクセス トークンは、実行時にジョブごとに Azure Pipelines によって動的に生成されるセキュリティ トークンです。 ジョブが実行されているエージェントは、Azure DevOps のこれらのリソースにアクセスするためにジョブ アクセス トークンを使用します。 ジョブ アクセス トークンにアクセス許可を付与する方法を制御することで、パイプラインがアクセスできるリソースを制御できます。

トークンのアクセス許可は、(a) ジョブの承認スコープ、および (b) プロジェクトまたはコレクションのビルド サービス アカウントで設定したアクセス許可から派生します。

ジョブの承認スコープ

ジョブの承認スコープをコレクションまたはプロジェクトに設定できます。 スコープをコレクションに設定すると、パイプラインがコレクションまたは組織内のすべてのリポジトリにアクセスできるようになります。 スコープをプロジェクトに設定すると、パイプラインと同じプロジェクト内にあるリポジトリのみにアクセスを制限できます。

YAML

ジョブの承認スコープは、Azure DevOps 組織全体または特定のプロジェクトに対して設定できます。

• すべてのプロジェクトの組織レベルでジョブの承認スコープを設定するには、[組織の設定]>[パイプライン]>[設定] を選択します。
• 特定のプロジェクトでジョブの承認スコープを設定するには、[プロジェクト設定]>[パイプライン]>[設定] を選択します。

次の 1 つ以上の設定を有効にします。 パイプラインのセキュリティが強化されるため、これらの設定を有効にすることをお勧めします。

• ジョブの承認スコープを非リリース パイプラインの現在のプロジェクトに制限する - この設定は、YAML パイプラインとクラシック ビルド パイプラインに適用され、クラシック リリース パイプラインには適用されません。
• ジョブの承認スコープをリリース パイプラインの現在のプロジェクトに制限する - この設定は、クラシック リリース パイプラインにのみ適用されます。

注意

スコープが組織レベルでプロジェクトに設定されている場合、各プロジェクトのスコープを変更することはできません。

重要

スコープが組織レベルでもプロジェクト レベルでも制限されていない場合、YAML パイプライン内のすべてのジョブは、コレクション スコープのジョブ アクセス トークンを取得します。 つまり、パイプラインは組織の任意のプロジェクトの任意のリポジトリにアクセスできます。 敵対者は、1 つのプロジェクト内の 1 つのパイプラインにアクセスできる場合、組織内の任意のリポジトリにアクセスできるようになります。 このため、攻撃を 1 つのプロジェクトに封じ込めるために、最高レベル (組織設定) でスコープを制限することをお勧めします。

クラシック

ジョブの承認スコープは、Azure DevOps 組織全体、特定のプロジェクト、または特定のパイプラインに対して設定できます。

• すべてのプロジェクトの組織レベルでジョブの承認スコープを設定するには、[組織の設定]>[パイプライン]>[設定] を選択します。
• 特定のプロジェクトでジョブの承認スコープを設定するには、[プロジェクト設定]>[パイプライン]>[設定] を選択します。

次の 1 つ以上の設定を有効にします。 パイプラインのセキュリティが強化されるため、これらの設定を有効にすることをお勧めします。

• ジョブの承認スコープを非リリース パイプラインの現在のプロジェクトに制限する - この設定は、YAML パイプラインとクラシック ビルド パイプラインに適用され、クラシック リリース パイプラインには適用されません。
• ジョブの承認スコープをリリース パイプラインの現在のプロジェクトに制限する - この設定は、クラシック リリース パイプラインにのみ適用されます。

注意

スコープが組織レベルでプロジェクトに設定されている場合、各プロジェクトのスコープを変更することはできません。

特定のパイプラインのジョブの承認のスコープを設定するには:

• [パイプライン] ページでパイプラインに移動します。
• [編集] を選択してパイプラインを編集します。
• [オプション] タブで、[ビルド ジョブの承認スコープ] として [プロジェクト コレクション] または [現在のプロジェクト] を選択します。
• ビルド パイプラインを保存します。

重要

スコープが組織レベルでもプロジェクト レベルでも制限されていない場合は、パイプライン作成者がリポジトリに対して必要なアクセスを決定できることになります。 敵対者は、1 つのプロジェクトでパイプラインを作成または編集できる場合、組織内の任意のリポジトリにアクセスできるようになります。 このため、攻撃を 1 つのプロジェクトに封じ込めるために、最高レベル (組織設定) でスコープを制限することをお勧めします。

注意

パイプラインがパブリック プロジェクトにある場合、設定で構成した内容に関係なく、ジョブの承認スコープは自動的にプロジェクトに制限されます。 パブリック プロジェクト内のジョブは、そのプロジェクト内でのみビルド成果物やテスト結果などのリソースにアクセスでき、組織の他のプロジェクトからはアクセスできません。

YAML パイプライン内のリポジトリへのアクセスを保護する

前のセクションで説明したジョブの承認スコープの設定に加えて、Azure Pipelines には、[YAML パイプライン内のリポジトリへのアクセスを保護する] の設定が用意されています。

[YAML パイプライン内のリポジトリへのアクセスを保護する] が有効になっていない限り、パイプラインは承認されたプロジェクト内の任意の Azure DevOps リポジトリにアクセスできます。 このオプションを有効にすると、すべてのパイプラインのアクセスのスコープを、そのリポジトリを使用するパイプライン ジョブの checkout ステップまたは uses ステートメントによって明示的に参照される Azure DevOps リポジトリのみに減らすことができます。

詳細については、「Azure Repos Git リポジトリ - YAML パイプライン内のリポジトリへのアクセスを保護する」を参照してください。

重要

[YAML パイプライン内のリポジトリへのアクセスを保護する] は、2020 年 5 月以降に作成された新しい組織とプロジェクトに対して既定で有効になっています。

スコープ付きビルド ID

Azure DevOps では、2 つの組み込み ID を使用してパイプラインを実行します。

• コレクション スコープの ID。コレクション (または Azure DevOps Services の組織) 内のすべてのプロジェクトにアクセスできます。
• プロジェクト スコープの ID。1 つのプロジェクトにアクセスできます

これらの ID には、Azure DevOps システムに呼び戻すときにビルド/リリース実行時のアクティビティを実行するために必要なアクセス許可が割り当てられます。 既定のアクセス許可が組み込まれており、必要に応じて独自のアクセス許可を管理することもできます。

コレクション スコープの ID 名の形式は次のとおりです。

• Project Collection Build Service ({OrgName})
• たとえば、組織名が fabrikam-tailspin の場合、このアカウントの名前は Project Collection Build Service (fabrikam-tailspin) です。

プロジェクト スコープの ID 名の形式は次のとおりです。

• {Project Name} Build Service ({Org Name})
• たとえば、組織名が fabrikam-tailspin で、プロジェクト名が SpaceGameWeb の場合、このアカウントの名前は SpaceGameWeb Build Service (fabrikam-tailspin) です。

既定では、前の「ジョブの承認スコープ」セクションで説明したように、特に構成されていない限り、コレクション スコープの ID が使用されます。

ビルド サービス アカウントのアクセス許可を管理する

プロジェクト スコープのアクセスを設定した結果の 1 つは、プロジェクト スコープの ID が、コレクション スコープの ID が持っていたリソースに対するアクセス許可を持っていない可能性があるということです。

次のようなシナリオでは、ジョブ アクセス トークンのアクセス許可を変更できます。

• パイプラインで、別のプロジェクト内のフィードにアクセスする必要があります。
• パイプラインで、リポジトリ内のコードの変更を制限する必要があります。
• パイプラインで作業項目の作成を制限する必要があります。

ジョブ アクセス トークンのアクセス許可を更新するには:

• まず、パイプラインのジョブの承認スコープを決定します。 ジョブの承認スコープについては、上記のセクションを参照してください。 ジョブの承認スコープがコレクションの場合、アクセス許可を管理するための対応するビルド サービス アカウントは、Project Collection Build Service (your-collection-name) です。 ジョブの承認スコープがプロジェクトの場合、アクセス許可を管理するためのビルド サービス アカウントは、Your-project-name Build Service (your-collection-name) です。

• Project Collection Build Service (your-collection-name) への追加アクセスを制限または許可するには:

  • [パイプライン] ページのオーバーフロー メニューで [セキュリティの管理] を選択します。
  • [ユーザー] で、[Project Collection Build Service (your-collection-name)] を選択します。
  • このアカウントのパイプライン関連のアクセス許可に変更を加えます。
  • Azure DevOps 組織の組織設定 (またはプロジェクト コレクションのコレクション設定) に移動します。
  • [セキュリティ] で [アクセス許可] を選択します。
  • [ユーザー] タブで、Project Collection Build Service (your-collection-name) を探します。
  • このアカウントのパイプライン関連以外のアクセス許可に変更を加えます。
  • Project Collection Build Service (your-collection-name) は組織またはコレクション内のユーザーであるため、このアカウントを任意のリソース (たとえば、Azure Artifacts のフィード) に明示的に追加できます。

• Your-project-name Build Service (your-collection-name) への追加アクセスを制限または許可するには:

  • アクセス許可を管理できるビルド サービス アカウントは、パイプラインを 1 回実行した後にのみ作成されます。 パイプラインを既に 1 回実行していることを確認します。
  • [パイプライン] ページのオーバーフロー メニューで [セキュリティの管理] を選択します。
  • [ユーザー] で、[Your-project-name Build Service (your-collection-name)] を選択します。
  • このアカウントのパイプライン関連のアクセス許可に変更を加えます。
  • Azure DevOps 組織の組織設定 (またはプロジェクト コレクションのコレクション設定) に移動します。
  • [セキュリティ] で [アクセス許可] を選択します。
  • [ユーザー] タブで、Your-project-name build service (your-collection-name) を探します。
  • このアカウントのパイプライン関連以外のアクセス許可に変更を加えます。
  • Your-project-name Build Service (your-collection-name) は組織またはコレクション内のユーザーであるため、このアカウントを任意のリソース (たとえば、Azure Artifacts のフィード) に明示的に追加できます。

同じプロジェクト コレクション内の別のプロジェクトにアクセスするためのプロジェクトのアクセス許可を構成する

この例では、fabrikam-tailspin/SpaceGameWeb プロジェクト スコープのビルド ID に、fabrikam-tailspin/FabrikamFiber プロジェクトにアクセスする権限が付与されます。

1. FabrikamFiber プロジェクトで、[プロジェクト設定]、[アクセス許可] に移動します。

   

2. 「外部プロジェクト」という名前の新しいグループを作成し、SpaceGameWeb Build Service アカウントを追加します。

3. [ユーザー] を選択し、「SpaceGameWeb」という名前の入力を開始して、SpaceGameWeb Build Service アカウントを選択します。 最初に検索結果が表示されない場合は、[検索の展開] を選択します。

   

4. そのユーザーに [プロジェクトレベル情報を表示します] アクセス許可を付与します。

   

例 - 同じプロジェクト コレクション内の別のリポジトリにアクセスするためのアクセス許可を構成する

この例では、fabrikam-tailspin/SpaceGameWeb プロジェクト スコープのビルド ID に、fabrikam-tailspin/FabrikamFiber プロジェクトの FabrikamFiber リポジトリにアクセスする権限が付与されます。

1. 手順に従って、FabrikamFiber プロジェクトにアクセスするための SpaceGameWeb プロジェクト スコープのビルド ID アクセス許可を付与します。

2. FabrikamFiber プロジェクトで、[プロジェクト設定]、[リポジトリ]、[FabrikamFiber] に移動します。

   

3. 「SpaceGameWeb」という名前の入力を開始し、SpaceGameWeb Build Service アカウントを選択します。

   

4. そのユーザーに対して読み取りアクセス許可を付与します。

   

例 - 同じプロジェクト コレクション内の他のリソースにアクセスするためのアクセス許可を構成する

この例では、fabrikam-tailspin/SpaceGameWeb プロジェクト スコープのビルド ID に、fabrikam-tailspin/FabrikamFiber プロジェクト内の他のリソースにアクセスする権限が付与されます。

1. 手順に従って、FabrikamFiber プロジェクトにアクセスするための SpaceGameWeb プロジェクト スコープのビルド ID アクセス許可を付与します。

2. そのユーザーに必要なアクセス許可を構成します。

   

よく寄せられる質問

YAML パイプラインのジョブの承認スコープを決定するにはどうすればよいですか?

• プロジェクトがパブリック プロジェクトの場合、他の設定に関係なく、ジョブの承認スコープは常にプロジェクトになります。

• パイプラインがプライベート プロジェクトにある場合は、Azure DevOps の [組織の設定] で [パイプライン] の設定を確認します。
  • [非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっている場合、スコープはプロジェクトになります。
  • [非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっていない場合は、Azure DevOps の [プロジェクト設定] の下にある [パイプライン] 設定を確認します。
    • [非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっている場合、スコープはプロジェクトになります。
    • それ以外の場合、スコープはコレクションです。

クラシック ビルド パイプラインのジョブの承認スコープを決定するにはどうすればよいですか?

• パイプラインがパブリック プロジェクト内にある場合、他の設定に関係なく、ジョブの承認スコープはプロジェクトになります。

• パイプラインがプライベート プロジェクトにある場合は、Azure DevOps の [組織の設定] で [パイプライン] の設定を確認します。
  • [非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっている場合、スコープはプロジェクトになります。
  • [非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっていない場合は、Azure DevOps の [プロジェクト設定] の下にある [パイプライン] 設定を確認します。
    • [非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっている場合、スコープはプロジェクトになります。
    • [非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっていない場合は、パイプラインのエディターを開き、[オプション] タブに移動します。
      • [ビルド ジョブの承認スコープ] が [現在のプロジェクト] の場合、スコープはプロジェクトです。
      • それ以外の場合、スコープはコレクションです。

新しいクラシック パイプラインを作成する場合、デフォルトでは、ジョブの承認スコープが現在のプロジェクトに設定され、ビルド ジョブの承認スコープがプロジェクトに設定されます。

クラシック リリース パイプラインのジョブの承認スコープを決定するにはどうすればよいですか?

• パイプラインがパブリック プロジェクト内にある場合、他の設定に関係なく、ジョブの承認スコープはプロジェクトになります。

• パイプラインがプライベート プロジェクトにある場合は、Azure DevOps の [組織の設定] で [パイプライン] の設定を確認します。
  • [リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっている場合、スコープはプロジェクトになります。
  • [リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっていない場合は、Azure DevOps の [プロジェクト設定] の下にある [パイプライン] 設定を確認します。
    • [リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] が有効になっている場合、スコープはプロジェクトになります。
    • それ以外の場合、スコープはコレクションです。