Azure Pipelines の無料付与の変更
ホストされるエージェントの悪用の増加に対処するために、Azure Pipelines の無料付与を取得するプロセスを一時的に変更しています。 既定では、Azure DevOps で作成された新しい組織は、同時実行パイプラインの無料付与を受け取らなくなる可能性があります。 新しいユーザーは、無料の CI/CD を取得するために電子メールを送信し、追加情報を提供する必要があります。
詳細については、以下の機能の一覧を参照してください。
Azure Pipelines
- Azure Pipelines の無料付与の変更
- クラシック ビルドでのパイプラインごとの保持ポリシーの削除
- パイプライン内の環境変数の新しいコントロール
- フォーク ビルドの無制限トークンを生成する
- Az、Azure、Azure RM のプレインストールモジュールの変更
Azure Repos
Azure Pipelines
Azure Pipelines の無料付与の変更
Azure Pipelines は、数年間、パブリックおよびプライベート プロジェクトに対して無料の CI/CD を提供してきました。 これは無料のコンピューティングを与えることに相当するため、常に不正使用 (特に暗号マイニング) のターゲットとなっています。 この不正使用を最小限に抑えることは、常にチームからエネルギーを取っています。 過去数か月間、Azure DevOps の新しいプロジェクトの高い割合が暗号化マイニングやその他のアクティビティに使用され、状況は大幅に悪化しています。 過去 1 か月間のいくつかのサービス インシデントは、この不正使用によって引き起こされ、既存の顧客の待機時間が長くなります。
この状況に対処するために、Azure DevOps の新しい組織が無料の許可を取得するための追加の手順を追加しました。 次の変更は直ちに有効です。
- 既定では、Azure DevOps で作成された新しい組織は、同時実行パイプラインの無料付与を受け取らなくなります。 これは、新しい組織のパブリック プロジェクトとプライベート プロジェクトの両方に適用されます。
- 無料の付与を要求するには、 要求を送信 し、次の詳細を明確に指定します。
- 名前
- 無料の付与を要求している Azure DevOps organization
- パブリック プロジェクトまたはプライベート プロジェクトの無料付与が必要かどうか
- ビルドする予定のリポジトリへのリンク (パブリック プロジェクトのみ)
- プロジェクトの簡単な説明 (パブリック プロジェクトのみ)
ご要望を確認し、数日以内に対応いたします。
Note
この変更は、新しい組織にのみ影響します。 既存のプロジェクトや組織には適用されません。 これにより、取得できる無料の許可の量は変更されません。 その無料付与を取得するための追加の手順のみが追加されます。
新しいお客様が CI/CD に Azure Pipelines を使用することを希望する場合、ご不便をおかけして申し訳ございません。 すべてのお客様に高いレベルのサービスを提供し続けるためには、これが必要であると考えています。 不正使用を防ぐ自動化された方法を引き続き検討し、不正使用を防ぐための信頼性の高いメカニズムが得られたら、前のモデルを復元します。
クラシック ビルドでのパイプラインごとの保持ポリシーの削除
Azure DevOps プロジェクト設定で、クラシック ビルドと YAML パイプラインの保持ポリシーを構成できるようになりました。 これは YAML パイプラインのリテンション期間を構成する唯一の方法ですが、パイプラインごとにクラシック ビルド パイプラインのリテンション期間を構成することもできます。 今後のリリースでは、クラシック ビルド パイプラインのすべてのパイプラインごとの保持ルールを削除します。
これが意味する内容: パイプラインごとのリテンション期間ルールがまだ残っているクラシック ビルド パイプラインは、すぐにプロジェクト レベルの保持ルールによって管理されます。
これらのパイプラインの特定に役立つよう、このリリースの変更をロールアウトして、実行リスト ページの上部にバナーを表示します。
パイプラインごとの保持ルールを削除して、パイプラインを更新することをお勧めします。 パイプラインに特にカスタム ルールが必要な場合は、パイプラインでカスタム タスクを使用できます。 タスクを通じて保持リースを追加する方法の詳細については、 ビルド、リリース、テストのセット保持ポリシーに関するドキュメントを参照してください。
パイプライン内の環境変数の新しいコントロール
Azure Pipelines エージェントは、特殊な ログ コマンド の標準出力をスキャンして実行します。 コマンドをsetVariable
使用して、変数を設定したり、以前に定義した変数を変更することができます。 これは、システム外のアクターによって悪用される可能性があります。 たとえば、パイプラインに ftp サーバー内のファイルの一覧を出力するステップがある場合、ftp サーバーにアクセスできるユーザーは新しいファイルを追加できます。このファイルの名前には コマンドが含まれており setVariable
、パイプラインの動作が変更されます。
パイプラインの logging コマンドを使用して変数を設定することに依存する多くのユーザーがいます。 このリリースでは、コマンドの不要な使用のリスクを軽減するために、次の変更を setVariable
行っています。
- タスク作成者用の新しいコンストラクトが追加されました。 に次
task.json
のようなスニペットを含めることで、タスク作成者は、タスクによって変数が設定されるかどうかを制御できます。
{
"restrictions": {
"commands": {
"mode": "restricted"
},
"settableVariables": {
"allowed": [
"myVar",
"otherVar"
]
}
},
}
さらに、ssh などの多くの組み込みタスクを更新して、悪用できないようにしています。
最後に、YAML コンストラクトを使用して、ステップで変数を設定できるかどうかを制御できるようになりました。
steps:
- script: echo hello
target:
settableVariables: none
steps:
- script: echo hello
target:
settableVariables:
- things
- stuff
フォーク ビルドの無制限トークンを生成する
GitHub ユーザーは、通常、フォークを使用してアップストリーム リポジトリに投稿します。 Azure Pipelines が GitHub リポジトリのフォークからコントリビューションビルドすると、ジョブ アクセス トークンに付与されるアクセス許可が制限され、そのようなジョブによるパイプライン シークレットへのアクセスは許可されません。 フォークの構築のセキュリティの詳細については、 こちらのドキュメントを参照してください。
GitHub Enterprise Server リポジトリのフォークをビルドする場合は、既定で同じ制限が適用されます。 これは、ユーザーが内部ソース コラボレーション モデルの恩恵を受ける可能性がある、このような閉じた環境では、必要以上に制限される可能性があります。 フォークでシークレットを使用できるようにパイプラインで設定を構成できますが、ジョブ アクセス トークンスコープを制御する設定はありません。 このリリースでは、フォークのビルドでも通常のジョブ アクセス トークンを生成する制御を提供しています。
この設定は、パイプライン エディター の [トリガー] から変更できます。 この設定を変更する前に、この構成を有効にすることのセキュリティへの影響を十分に理解しておく必要があります。
Az、Azure、Azure RM のプレインストールモジュールの変更
より効率的なサポートとイメージ領域の使用のために、Az、Azure、AzureRM モジュールを Ubuntu および Windows でホストされているイメージにプレインストールするプロセスを更新しています。
3 月 29 日の週の間に、最新バージョンと最も人気のあるバージョンを除くすべてのバージョンがアーカイブとして保存され、Azure PowerShellタスクによってオンデマンドで抽出されます。 変更の詳細な一覧を次に示します。
Windows イメージ
最新バージョン (現在、5.5.0) を除くすべての Az モジュール バージョンがアーカイブされます
最新のモジュール (現在は 5.3.0) と 2.1.0 を除くすべての Azure モジュールがアーカイブされます
最新のモジュール (現在は 6.13.1) と 2.1.0 を除くすべての AzureRM モジュールがアーカイブされます
Ubuntu イメージ
- 最新のモジュール (現在は 5.5.0) を除くすべての Az モジュールは、イメージから完全にアーカイブまたは削除され、タスクによってオンデマンドでインストールされます。
ホストされているエージェントですぐに使用できる Azure タスクを使用するパイプラインは、意図したとおりに動作し、更新は必要ありません。 これらのタスクを使用しない場合は、パイプラインを Azure PowerShell タスクを使用するように切り替えて、プレインストール済みモジュールの変更を回避します。
Note
これらの更新は、セルフホステッド エージェントで実行されているパイプラインには影響しません。
Azure Repos
リポジトリを無効にする
多くの場合、お客様はリポジトリを無効にし、ユーザーがそのコンテンツにアクセスできないようにする方法を要求しています。 たとえば、次の場合にこれを行うことができます。
- リポジトリにシークレットが見つかりました。
- サードパーティのスキャン ツールで、リポジトリがコンプライアンス違反であることが検出されました。
このような場合は、問題の解決に取り組んでいる間にリポジトリを一時的に無効にすることができます。 この更新プログラムでは、リポジトリの削除アクセス許可がある場合は 、リポジトリを 無効にすることができます。 リポジトリを無効にすると、次の操作が行われます。
- リポジトリの一覧でリポジトリを一覧表示できます
- リポジトリの内容を読み取れません
- リポジトリの内容を更新できません
- Azure Repos UI でリポジトリにアクセスしようとしたときに、リポジトリが無効になっていることを示すメッセージを表示する
必要な軽減策を実行した後、 リポジトリの削除 アクセス許可を持つユーザーは、リポジトリを再度有効にすることができます。 リポジトリを無効または有効にするには、[プロジェクトの設定] に移動し、[リポジトリ] を選択してから、特定のリポジトリを選択します。
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に進み、見てみましょう。
フィードバックの提供方法
これらの機能についてご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
ヴィジャイ・マキラジュ
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示