プールの作成時に[セキュリティ]タブを使用し、[ セキュリティ 設定]ペインを使用してプールの作成後に、マネージド DevOps プールの セキュリティ 設定を構成できます。
既定では、Managed DevOps プールは、組織内のすべてのプロジェクトに付与されたプールへのアクセス権を持つ単一の組織用に構成されます。 必要に応じて、組織内の特定のプロジェクトへのアクセスを制限したり、必要に応じて追加の組織へのアクセスを許可したりできます。
1 つの組織でプールを使用する
既定では、Managed DevOps プールは、プールの作成時に指定する単一の Azure DevOps 組織で使用するように構成されています。 プールが 1 つの組織用に構成されている場合、組織名が表示され、[プールの設定] に構成されます
既定では、[ すべてのプロジェクトにプールを追加 ] は [はい] に設定され、Managed DevOps プールへのアクセスは組織内のすべてのプロジェクトに付与されます。 [ いいえ ] を選択して、プールを使用できる組織内のプロジェクトを制限するプロジェクトの一覧を指定します。
組織は、Managed DevOps Pools リソースの organizationProfile プロパティで構成されます。
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"name": "fabrikam-managed-pool",
"type": "microsoft.devopsinfrastructure/pools",
"apiVersion": "2025-01-21",
"___location": "eastus",
"properties": {
...
"organizationProfile": {
"organizations": [
{
"url": "https://dev.azure.com/fabrikam-tailspin",
"projects": [],
"parallelism": 4
}
],
"permissionProfile": {
"kind": "CreatorOnly"
},
"kind": "AzureDevOps"
}
}
]
}
organizationProfile セクションには、次のプロパティがあります。
| プロパティ |
説明 |
organizations |
プールを使用できる組織の一覧。
url は組織の URL を指定します。 projects はプールを使用できるプロジェクト名の一覧であり (空のリストは組織内のすべてのプロジェクトをサポートします)、 parallelism はこの組織で使用できるエージェントの数を指定します。 組織の並列処理の合計は、プールの最大エージェント設定と一致する必要があります。 |
permissionProfile |
Azure DevOps プールの作成時に付与されるアクセス許可を指定します。 この値は、プールの作成時にのみ設定できます。 使用できる値は、Inherit、CreatorOnly、および SpecificAccounts です。
specificAccountsを指定する場合は、1 つの電子メール アドレスまたは users プロパティの電子メール アドレスの一覧を指定します。それ以外の場合は、usersを省略します。 詳細については、「 プール管理のアクセス許可」を参照してください。 |
kind |
この値は、プールの組織の種類を指定し、 Azure DevOpsに設定する必要があります。 |
組織は、プールのorganization-profileまたは更新時に パラメーターで構成されます。
az mdp pool create \
--organization-profile organization-profile.json
# other parameters omitted for space
次の例は、organization-profileが fabrikam-tailspin に設定されたparallelism組織内のすべてのプロジェクトに対して構成されている1 オブジェクトを示しています。
{
"AzureDevOps":
{
"organizations": [
{
"url": "https://dev.azure.com/fabrikam-tailspin",
"projects": [],
"parallelism": 1
}
]
}
}
organizationProfile セクションには、次のプロパティがあります。
| プロパティ |
説明 |
AzureDevOps |
この値は、 organization-profile で定義されているオブジェクトの名前であり、 Azure DevOpsに設定する必要があります。 |
organizations |
プールを使用できる組織の一覧。
openAccess は、プールの作成時にマネージド DevOps プールがプールの オープン アクセス を構成するかどうかを指定 url 、 projects はプールを使用できるプロジェクト名のリストです (空のリストは組織内のすべてのプロジェクトをサポートします)、 parallelism は、この組織で使用できるエージェントの数を指定します。 組織の並列処理の合計は、プールの最大エージェント設定と一致する必要があります。 |
permissionProfile |
Azure DevOps プールの作成時に付与されるアクセス許可を指定します。 この値は、プールの作成時にのみ設定できます。 使用できる値は、Inherit、CreatorOnly、および SpecificAccounts です。
specificAccountsを指定する場合は、1 つの電子メール アドレスまたは users プロパティの電子メール アドレスの一覧を指定します。それ以外の場合は、usersを省略します。 詳細については、「 プール管理のアクセス許可」を参照してください。 |
複数の組織でプールを使用する
複数の組織でプールを使用して、複数の Azure DevOps 組織でプールを使用できるようにします。 各組織について、プールの使用を許可するプロジェクトを指定するか、空白のままにしてすべてのプロジェクトを許可します。 プールの最大エージェントで指定されたコンカレンシーの各部分を各組織に割り当てることで、各組織の並列処理を設定します。 すべての組織の並列処理の合計は、プールの最大コンカレンシーと等しい必要があります。 たとえば、 最大エージェント が 5 に設定されている場合、指定した組織の並列処理の合計は 5 である必要があります。
最大エージェントが 1 に設定されている場合、プールは 1 つの組織でのみ使用できます。
次の例では、プールは fabrikam-tailspin 組織の FabrikamResearch プロジェクトと FabrikamTest プロジェクト、および fabrikam-blue 組織内のすべてのプロジェクトで使用できるように構成されています。
The sum of parallelism for all organizations must equal the max concurrency.などのエラーが発生した場合は、プールの最大エージェント数が並列処理列の合計と一致していることを確認します。
組織の一覧に組織を追加して、複数の組織で使用するようにプールを構成します。 次の例では、2 つの組織が構成されています。 最初の組織はすべてのプロジェクトにマネージド DevOps プールを使用するように構成され、2 番目の組織は 2 つのプロジェクトに制限されています。 この例では、プールのエージェントの最大設定は 4 であり、各組織はこれら 4 つのエージェントのうち 2 つを使用できます。
"organizationProfile": {
"organizations": [
{
"url": "https://dev.azure.com/fabrikam-tailspin",
"projects": [],
"parallelism": 2
},
{
"url": "https://dev.azure.com/fabrikam-prime",
"projects": [ "fabrikam-dev", "fabrikam-test" ],
"parallelism": 2
}
],
"permissionProfile": {
"kind": "CreatorOnly"
},
"kind": "AzureDevOps"
}
組織は、プールのorganization-profileまたは更新時に パラメーターで構成されます。
az mdp pool create \
--organization-profile organization-profile.json
# other parameters omitted for space
組織の一覧に組織を追加して、複数の組織で使用するようにプールを構成します。 次の例では、2 つの組織が構成されています。 最初の組織はすべてのプロジェクトにマネージド DevOps プールを使用するように構成され、2 番目の組織は 2 つのプロジェクトに制限されています。 この例では、プールのエージェントの最大設定は 4 であり、各組織はこれら 4 つのエージェントのうち 2 つを使用できます。
{
"AzureDevOps":
{
"organizations": [
{
"url": "https://dev.azure.com/fabrikam-tailspin",
"projects": [],
"parallelism": 2
},
{
"url": "https://dev.azure.com/fabrikam-prime",
"projects": [ "fabrikam-dev", "fabrikam-test" ],
"parallelism": 2
}
]
}
}
パイプラインのオープン アクセスを構成するには、「 前提条件 - Azure DevOps のアクセス許可を確認する」で説明されているアクセス許可に加えて、次のアクセス許可が必要です。
既定では、すべてのパイプライン定義は、そのプールで初めて実行される前に、セルフホステッド エージェント プール (Managed DevOps プールなど) で実行することを明示的に承認する必要があります。
Azure DevOps には、エージェント プールで実行するパイプラインを承認するための次のモードが用意されています。
-
特定のパイプラインを承認する - プールで実行する Azure DevOps プロジェクトの特定のパイプラインを個別に承認します。 この方法は既定です。
-
オープン アクセス - プロジェクト レベルでエージェント プールを構成し、そのプロジェクト内のすべてのパイプラインで使用できるようにします。
プールの作成時に Azure DevOps でオープン アクセス エージェント プール設定を構成するために、承認 (オープン アクセス) なしですべてのパイプラインをプールで実行できるようにするを有効にします。
注
[ 承認なしですべてのパイプラインをプールで実行することを許可する (オープン アクセス)] 設定は、プールが作成されたときにのみ、Managed DevOps プールで構成できます。 Managed DevOps プールが作成されたら、プールを使用するプロジェクトごとに、Azure DevOps 内の対応するエージェント プールに対するオープン アクセスを表示および構成できます。
指定されたプロジェクト内のすべてのパイプラインから Managed DevOps プールへのアクセスを構成するために、 承認 (オープン アクセス) なしで すべてのパイプラインをプールで実行できるようにするを有効にします。
-
[すべてのプロジェクトにプールを追加する] が [はい] に設定されている場合、Managed DevOps Pools は、すべてのプロジェクトのすべてのパイプラインに対してオープン アクセスを構成します。
-
[すべてのプロジェクトにプールを追加する] が [いいえ] に設定されている場合、Managed DevOps Pools では、一覧に記載されているプロジェクト内のすべてのパイプラインに対してオープン アクセスが構成されます。
複数の組織で [プールの使用] を有効にした場合は、組織ごとに個別にオープン アクセスを指定できます。
注
以降を使用する場合は、[api-version 2025-01-21] 設定が表示されます。
組織は、Managed DevOps Pools リソースの organizationProfile プロパティで構成されます。 次の例では、2 つの組織が構成されています。
-
fabrikam-tailspin組織は、すべてのプロジェクトでオープン アクセスを使用して構成されます。
-
fabrikam-prime組織は、これら 2 つのプロジェクトでのみオープン アクセスが有効になっている 2 つのプロジェクトで可用性を確保するように構成されています。
"organizationProfile": {
"organizations": [
{
"url": "https://dev.azure.com/fabrikam-tailspin",
"projects": [],
"openAccess": true,
"parallelism": 2
},
{
"url": "https://dev.azure.com/fabrikam-prime",
"projects": [ "fabrikam-dev", "fabrikam-test" ],
"openAccess": true,
"parallelism": 2
}
],
"permissionProfile": {
"kind": "CreatorOnly"
},
"kind": "AzureDevOps"
}
重要
オープン アクセス は、Managed DevOps プールの作成時にのみ構成されます。 プールの作成後にオープン アクセス設定 (Managed DevOps プール構成のプロジェクトの追加または削除を含む) を変更するには、プールを使用するプロジェクトごとに、Azure DevOps 内の対応するエージェント プールに対するオープン アクセスを手動で構成する必要があります。
openAccess設定は、プールのorganization-profileに パラメーターで構成されます。
az mdp pool create \
--organization-profile organization-profile.json
# other parameters omitted for space
次の orgaization-profile 例では、2 つの組織が構成されています。
-
fabrikam-tailspin組織は、すべてのプロジェクトでオープン アクセスを使用して構成されます。
-
fabrikam-prime組織は、これら 2 つのプロジェクトでのみオープン アクセスが有効になっている 2 つのプロジェクトで可用性を確保するように構成されています。
{
"AzureDevOps":
{
"organizations": [
{
"url": "https://dev.azure.com/fabrikam-tailspin",
"projects": [],
"parallelism": 2
},
{
"url": "https://dev.azure.com/fabrikam-prime",
"projects": [ "fabrikam-dev", "fabrikam-test" ],
"parallelism": 2
}
]
}
}
重要
オープン アクセス は、Managed DevOps プールの作成時にのみ構成されます。 プールの作成後にオープン アクセス設定 (Managed DevOps プール構成のプロジェクトの追加または削除を含む) を変更するには、プールを使用するプロジェクトごとに、Azure DevOps 内の対応するエージェント プールに対するオープン アクセスを手動で構成する必要があります。
エージェント プールへのアクセスが承認されていないパイプラインを実行しようとすると、 This pipeline needs permission to access a resource before this run can continueのようなエラーが表示されます。 この問題を解決するには、前のセクションで説明したようにオープン アクセスを構成するか、 エージェント プールで実行するパイプラインを明示的に承認します。
テストで UI テスト用の対話型ログインが必要な場合は、 EnableInteractiveMode 設定を有効にして対話型ログインを有効にします。
対話型モードは、osProfile プロパティの fabricProfile セクションで構成されます。
logonTypeをInteractiveに設定して対話型モードを有効にするか、対話モードを無効にするServiceします。
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"name": "fabrikam-managed-pool",
"type": "microsoft.devopsinfrastructure/pools",
"apiVersion": "2025-01-21",
"___location": "eastus",
"properties": {
...
"fabricProfile": {
"sku": {...},
"images": [...],
"osProfile": {
"secretsManagementSettings": {...},
"logonType": "Interactive"
},
"storageProfile": {...},
"kind": "Vmss"
}
}
]
}
対話型モードは、プールの作成時またはlogonType時に、osProfile パラメーターの fabric-profile セクションの プロパティを使用して構成されます。
az mdp pool create \
--fabric-profile fabric-profile.json
# other parameters omitted for space
次の例は、osProfile モードが有効になっている fabric-profile.json ファイルのInteractive セクションを示しています。
{
"vmss": {
"sku": {...},
"images": [...],
"osProfile": {
"secretsManagementSettings": {...},
"logonType": "Interactive"
},
"storageProfile": {...}
}
}
プール管理のアクセス許可
マネージド DevOps プール作成プロセスの一環として、組織レベルのエージェント プールが Azure DevOps に作成されます。
プール管理のアクセス許可の設定では、新しく作成された Azure DevOps プールの管理者ロールを付与するユーザーを指定します。 Managed DevOps プールの作成後に Azure DevOps エージェント プールのアクセス許可を表示 および管理するには、「エージェント プールの作成と管理 - エージェント プールのセキュリティ」を参照してください。
-
作成者のみ - Managed DevOps プールを作成したユーザーが Azure DevOps エージェント プールの管理者として追加され、エージェント プールのセキュリティ設定で 継承 が [オフ ] に設定されます。
作成者のみが 既定の設定です。
-
プロジェクトからアクセス許可を継承 する - Managed DevOps プールを作成したユーザーは Azure DevOps エージェント プールの管理者として 追加され、 継承はエージェント プールのセキュリティ設定で [オン] に設定されます。
-
特定のアカウント - Azure DevOps で作成されたエージェント プールの管理者として追加するアカウントを指定します。 既定では、Managed DevOps プールの作成者が一覧に追加されます。
プール管理アクセス許可は、Managed DevOps Pools リソースの permissionsProfile セクションの organizationProfile プロパティで構成されます。
{
"organizationProfile": {
"organizations": [...],
"permissionProfile": {
"kind": "CreatorOnly"
},
"kind": "AzureDevOps"
}
permissionProfile プロパティは、プールの作成時にのみ設定できます。 使用できる値は、Inherit、CreatorOnly、および SpecificAccounts です。
CreatorOnly - Managed DevOps プールを作成したユーザーが Azure DevOps エージェント プールの管理者として追加され、エージェント プールのセキュリティ設定で [継承 ] が [オフ ] に設定されます。
作成者のみが 既定の設定です。
Inherit - Managed DevOps プールを作成したユーザーは Azure DevOps エージェント プールの管理者として追加され、 継承 はエージェント プールのセキュリティ設定で [オン] に設定されます。
SpecificAccounts - Azure DevOps で作成されたエージェント プールの管理者として追加するアカウントを指定します。 既定では、Managed DevOps プールの作成者が一覧に追加されます。
users プロパティの 1 つの電子メール アドレスまたは電子メール アドレスの一覧を指定します。それ以外の場合はusersを省略します。
{
"organizationProfile": {
"organizations": [...],
"permissionProfile": {
"kind": "SpecificAccounts",
"users" : ["User1@fabrikam.com", "User2@fabrikam.com" ]
},
"kind": "AzureDevOps"
}
プール管理のアクセス許可は、プールのorganization-profileに パラメーターで構成されます。
az mdp pool create \
--organization-profile organization-profile.json
# other parameters omitted for space
{
"AzureDevOps":
{
"organizations": [...],
"permissionProfile": {
"kind": "CreatorOnly"
}
}
}
permissionProfile プロパティは、プールの作成時にのみ設定できます。 使用できる値は、Inherit、CreatorOnly、および SpecificAccounts です。
CreatorOnly - Managed DevOps プールを作成したユーザーが Azure DevOps エージェント プールの管理者として追加され、エージェント プールのセキュリティ設定で [継承 ] が [オフ ] に設定されます。
作成者のみが 既定の設定です。
Inherit - Managed DevOps プールを作成したユーザーは Azure DevOps エージェント プールの管理者として追加され、 継承 はエージェント プールのセキュリティ設定で [オン] に設定されます。
SpecificAccounts - Azure DevOps で作成されたエージェント プールの管理者として追加するアカウントを指定します。 既定では、Managed DevOps プールの作成者が一覧に追加されます。
users プロパティの 1 つの電子メール アドレスまたは電子メール アドレスの一覧を指定します。それ以外の場合はusersを省略します。
{
"AzureDevOps" : {
"organizationProfile": {
"organizations": [...],
"permissionProfile": {
"kind": "SpecificAccounts",
"users" : ["User1@fabrikam.com", "User2@fabrikam.com" ]
}
}
}
Key Vault の構成
マネージド DevOps プールは、プロビジョニング中に Azure Key Vault から証明書をフェッチする機能を提供します。つまり、パイプラインを実行する時点までに、証明書はマシン上に既に存在します。
この機能を使用するには、次の操作を行う必要があります。
注
api-version 2025-01-21時点では、この機能を使用する場合は、プールで 1 つの ID のみを使用できます。 複数の ID のサポートは近日中に追加される予定です。
Key Vault からシークレットをフェッチするために使用できる ID は 1 つだけです。
Managed DevOps Pools 証明書の設定はプール レベルで設定され、一部の設定は Windows または Linux に固有です。 ワークフローで Linux イメージと Windows イメージの両方が必要な場合は、Windows と Linux の両方で動作する共通の証明書設定のセットが見つからない場合は、それらを複数のプールに分割する必要があります。
次の設定では、Key Vault からフェッチされた証明書を構成します。
証明書 (observedCertificates)
Key Vault からフェッチし、プール内のすべてのマシンにインストールする証明書を指定します。
証明書ストアの場所 (certificateStoreLocation)
エージェントに証明書をインストールする場所を指定します。
-
Windows エージェント:
LocalMachine または CurrentUserを指定します。
-
Linux エージェント: 証明書ストアの場所 は、Ubuntu ディストリビューションでのみサポートされます。 証明書を格納するディスク パスを指定します (例:
/var/lib/waagent/Microsoft.Azure.KeyVault/app1)。
Ubuntu ディストリビューションの場合、信頼できるストアの場所 ( /usr/local/share/ca-certificatesなど) を指定すると、証明書がその証明書ストアにルートとして追加されます。 詳細については、「 信頼ストアにルート CA 証明書をインストールする」を参照してください。
証明書ストア名 (certificateStoreName)
-
Windows エージェント:
My (ローカル証明書ストア - 名前が指定されていない場合は既定) または Root (信頼されたルートの場所) のいずれかの証明書ストアの名前を指定します。
-
Linux エージェント: この設定は Linux エージェントでは使用されません。
エクスポート可能な秘密キー (keyExportable)
証明書のキーがエクスポート可能かどうか。 既定値は falseです。
Key Vault の統合は 、[設定] > [セキュリティ] で構成されます。
注
Key Vault 統合設定は、プールの作成後にのみ構成できます。 Key Vault 統合設定はプールの作成時に構成できません。また、プールの作成時に [ セキュリティ ] タブには表示されません。
Azure Key Vault は、osProfile プロパティの fabricProfile セクションで構成されます。 目的の証明書にアクセスできるように secretManagementSettings を設定します。
注
osProfile.certificateStoreName プロパティは、apiVersion 2025-01-21 以降でのみ使用できます。
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"name": "fabrikam-managed-pool",
"type": "microsoft.devopsinfrastructure/pools",
"apiVersion": "2025-01-21",
"___location": "eastus",
"properties": {
...
"fabricProfile": {
"sku": {...},
"images": [...],
"osProfile": {
"secretsManagementSettings": {
"certificateStoreLocation": "LocalMachine",
"certificateStoreName": "Root",
"observedCertificates": [
"https://<keyvault-uri>/secrets/<certificate-name>"
],
"keyExportable": false
}
},
"storageProfile": {...},
"kind": "Vmss"
}
}
]
}
Azure Key Vault は、プールのosProfileまたはfabricProfile時に、 プロパティの セクションで構成されます。 目的の証明書にアクセスできるように secretManagementSettings を設定します。
az mdp pool create \
--fabric-profile fabric-profile.json
# other parameters omitted for space
次の例は、fabric-profile.jsonファイルの osProfile セクションをsecretsManagementSettings構成済みで示しています。
{
"vmss": {
"sku": {...},
"images": [...],
"osProfile": {
"secretsManagementSettings": {
"certificateStoreLocation": "LocalMachine",
"observedCertificates": [
"https://<keyvault-uri>/secrets/<certificate-name>"
],
"keyExportable": false
},
"logonType": "Interactive"
},
"storageProfile": {...}
}
}
SecretManagementSettings の構成
プール上の SecretManagementSettings を使用して取得された証明書は、Key Vault 内で発行された最新バージョンと自動的に同期されます。 これらのシークレットは、最初のパイプラインを実行する時点までにマシン上に配置されます。つまり、時間を節約し、証明書をフェッチするためのタスクを削除できます。
重要
アクセス許可またはネットワークの問題が原因でシークレットを Key Vault からフェッチできない場合、エージェント仮想マシンのプロビジョニングは失敗します。
Windows の場合、証明書ストアの場所は、 LocalMachine または CurrentUserに設定できます。 この設定により、シークレットがマシン上のその場所に確実にインストールされます。 シークレットの取得のしくみの具体的な動作については、 Windows 用の Azure Key Vault 拡張機能を参照してください。
Linux の場合、証明書ストアの場所はコンピューター上の任意のディレクトリにすることができ、証明書はダウンロードされ、その場所に同期されます。 既定の設定とシークレットの動作の詳細については、 Linux 用の Key Vault 仮想マシン拡張機能に関するページを参照してください。
関連項目
