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 組織
- パブリック プロジェクトまたはプライベート プロジェクトの無料付与が必要かどうか
- ビルドする予定のリポジトリへのリンク (パブリック プロジェクトのみ)
- プロジェクトの簡単な説明 (パブリック プロジェクトのみ)
お客様のリクエストを確認し、数日以内に返信します。
Note
この変更は、新しい組織にのみ影響します。 既存のプロジェクトや組織には適用されません。 これにより、取得できる無料の許可の量は変更されません。 その無料付与を取得するための追加の手順のみが追加されます。
新しいお客様が CI/CD に Azure Pipelines を使用することを希望する場合、ご不便をおかけして申し訳ございません。 引き続きお客様に高いレベルのサービスを提供するためには、これが必要だと考えています。 不正使用を防止する自動化された方法を引き続き検討し、不正使用を防ぐ信頼性の高いメカニズムが得られたら、以前のモデルを復元します。
クラシック ビルドでのパイプラインごとの保持ポリシーの削除
Azure DevOps プロジェクト設定で、クラシック ビルドと YAML パイプラインの保持ポリシーを構成できるようになりました。 これは YAML パイプラインのリテンション期間を構成する唯一の方法ですが、パイプラインごとにクラシック ビルド パイプラインのリテンション期間を構成することもできます。 今後のリリースでは、クラシック ビルド パイプラインのパイプラインごとのリテンション期間ルールをすべて削除します。
つまり、パイプラインごとのリテンション期間ルールがまだ残っているクラシック ビルド パイプラインは、間もなくプロジェクト レベルの保持ルールによって管理されます。
これらのパイプラインを特定しやすくするために、このリリースでは、実行リスト ページの上部にバナーが表示されるように変更をロールアウトしています。
パイプラインごとの保持ルールを削除して、パイプラインを更新することをお勧めします。 パイプラインにカスタム ルールが特に必要な場合は、パイプラインでカスタム タスクを使用できます。 タスクを通じて保持リースを追加する方法については、ビルド、リリース、テストの セットの保持ポリシーに関するドキュメントを参照してください。
パイプライン内の環境変数の新しいコントロール
Azure Pipelines エージェントは、標準出力で特殊な ログ コマンドをスキャンし それらを実行します。 setVariable
commandを使用して、変数を設定したり、以前に定義した変数を変更することができます。 これは、システムの外部にあるアクターによって悪用される可能性があります。 たとえば、パイプラインに ftp サーバー内のファイルの一覧を出力する手順がある場合、ftp サーバーにアクセスできるユーザーは、 setVariable
コマンドを含む名前の新しいファイルを追加し、パイプラインの動作を変更できます。
パイプラインでログコマンドを使用して変数を設定することに依存する多くのユーザーがいます。 このリリースでは、 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 リポジトリのフォークを構築する場合は、既定で同じ制限が適用されます。 これは、ユーザーが内部ソースのコラボレーション モデルの恩恵を受ける可能性がある、このような閉じた環境では、望ましいよりも制限が厳しい場合があります。 パイプラインで設定を構成してシークレットをフォークで使用できるようにすることはできますが、ジョブ アクセス トークンスコープを制御する設定はありません。 このリリースでは、フォークのビルドでも通常のジョブ アクセス トークンを生成する制御を提供しています。
この設定は、パイプライン エディターの Triggers から変更できます。 この設定を変更する前に、この構成を有効にした場合のセキュリティへの影響を十分に理解しておいてください。
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 でリポジトリにアクセスしようとしたときに、リポジトリが無効にされたことを示すメッセージを表示する
必要な軽減手順を実行した後、 Delete リポジトリ アクセス許可を持つユーザーは、リポジトリを再度有効にすることができます。 リポジトリを無効または有効にするには、[プロジェクトの設定] に移動し、[リポジトリ] を選択してから、特定のリポジトリを選択します。
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に向かい、見てみましょう。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
ヴィジャイ・マクラジュ