ホスティングエージェントの悪用が増えていることに対応するため、Azure Pipelinesの無償実行時間を取得するプロセスを一時的に変更します。デフォルトでは、Azure DevOpsで作成された新しい組織は、並列パイプラインの無償実行時間の提供を受けられなくなります。新しいユーザーは、CI/CDの無料実行時間を取得する場合、電子メールを送信し、追加情報を提供する必要があります。
今回提供する機能の詳細は以下をご覧ください。
- Azure Pipelinesの無料実行時間提供の方法が変わります
- クラッシックビルドでのパイプライン単位の保持ポリシーが削除されます
- パイプラインで環境変数の上書き制御ができるようになりました
- 信頼されないフォークされたレポジトリーでトークンが使えるようになります
- Az, Azure, Azure RMモジュールのプリインストールは最新版だけになります
Azure Pipelinesは、数年前からパブリックおよびプライベートプロジェクトにCI/CDを無料で提供しています。これは無料で計算機を提供することになるため、常に悪用の対象となってきました。とくに暗号のマイニングなどです。この悪用を最小限に抑えることは、常にチームのエネルギーを必要としてきました。ここ数カ月、状況は大幅に悪化しており、Azure DevOpsの新規プロジェクトの多くが、マイニングのための暗号計算やその他の不正行為に使用されていました。過去1か月間に発生したいくつかのサービスインシデントは、この不正使用のために、既存のお客様の待ち時間が長くなっています。
このような状況に対処するため、Azure DevOpsの新規組織が無料のグラントを取得するための特別なステップを追加しました。以下の変更は直ちに有効です。
- デフォルトでは、Azure DevOpsで作成された新しいorganizationに対して、並列実行パイプラインの無料付与が与えられなく。これは、新しいorganizationのパブリックプロジェクトとプライベートプロジェクトの両方に適用されます。
- 無償供与を申請するには、
azpipelines-freetier@microsoft.comにメールを送り、以下の詳細をはっきりと伝えてください。- お名前
- 無償供与を申請するAzure DevOps organization
- パブリックプロジェクト、プライベートプロジェクト、またはその両方のために無償実行時間を必要としているかどうか
- 構築を予定しているリポジトリへのリンク（パブリックプロジェクトのみ）
- プロジェクトの簡単な説明（パブリックプロジェクトのみ）
メールをいただいてから数日中に申請内容を確認し、回答いたします。
注意事項
この変更は、新しいorganizationにのみ影響します。既存のプロジェクトやorganizationには適用されません。この変更は、無料の実行時間上限を変更するものではありません。無料の実行時間を取得するためのステップが追加されるだけです。
今回の変更により、Azure PipelinesによるCI/CDをご希望の新規のお客様にはご不便をおかけします。すべてのお客様に高レベルのサービスを提供し続けるためには、これが必要だと考えています。乱用を防ぐための自動化された方法を引き続き検討し、信頼できる仕組みができたら以前のモデルに戻す予定です。
Azure DevOpsのプロジェクト設定で、クラシックビルドとYAMLパイプラインの保持ポリシーを設定できるようになりました。これは、YAMLパイプラインの保持を設定する唯一の方法ですが、クラシックビルドパイプラインの保持をパイプラインごとに設定することもできます。今後のリリースでは、クラシックビルドパイプラインのパイプラインごとの保持ルールをすべて削除する予定です。
まもなく、パイプラインごとの保持ルールを持つクラシックビルドパイプラインは、プロジェクトレベルの保持ルールによって管理されることになります。
これらのパイプラインを識別するために、今回のリリースでは、実行結果リストページの上部にバナーを表示するように変更しています。
パイプラインごとの保持ルールを削除して、パイプラインを更新することをお勧めします。特別なパイプラインのために独自のルールが必要な場合、パイプラインでカスタムタスクが設定できます。タスクを使って保持のリース情報を追加する方法については、set retention policies for builds, releases, and testsのドキュメントを参照してください。
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: nonesteps:
- script: echo hello
target:
settableVariables:
- things
- stuffGitHubユーザーは、アップストリームのリポジトリへ貢献するために一般的にフォークを使います。Azure PipelinesがGitHubリポジトリのフォークからコントリビューションをビルドする場合、ジョブのアクセストークンに付与される権限を制限しているため、ジョブによるパイプラインシークレットへのアクセスを許可しません。フォークレポジトリーに対してビルド実行する際のセキュリティについては、ドキュメントで詳しく説明されています。
GitHub Enterprise Server リポジトリのフォークをビルドする際にも、デフォルトで同じ制限が適用されます。このような閉鎖的な環境では、ユーザーがインナーソースコラボレーションモデルの恩恵を受けられる可能性があるので、必要以上に制限されるかもしれません。シークレットをフォークで利用できるようにする設定をパイプラインで行うことはできますが、ジョブのアクセストークンスコープを制御する設定はありません。今回のリリースでは、フォークのビルドであっても通常のジョブアクセストークンを生成するようにコントロールできるようになりました。
この設定は、パイプラインエディターのTriggersから変更できます。この設定を変更する前に、この設定を有効にすることによるセキュリティ上の影響を十分に理解しておいてください。
より効率的なサポートとイメージスペースの有効活用のために、Az、Azure、およびAzureRMモジュールをUbuntuおよびWindowsホストイメージにプレインストールするプロセスを更新します。
3月29日の週に、最新のものと、もっとも人気のあるものを除くすべてのバージョンがアーカイブとして保存され、必要に応じてAzure PowerShellタスクによって抽出されるようになります。変更点の詳細なリストは以下の通りです。
- Windowsイメージ
- 最新バージョン（現在は5.5.0）を除くすべてのAzureモジュールのバージョンがアーカイブ化されます。
- 最新版（現在は5.3.0）と2.1.0を除くすべてのAzureモジュールがアーカイブ化されます。
- 最新のもの（現在は6.13.1）と2.1.0を除くすべてのAzureRMモジュールがアーカイブ化されます。
- Ubuntuイメージ
- 最新のモジュール（現在は5.5.0）を除くすべてのAzureRMモジュールがアーカイブ化されるか、イメージから完全に削除され、必要に応じてタスクによってインストールされます。
ホストエージェントに組み込まれたAzureタスクを使用するパイプラインは、意図したとおりに動作し、アップデートは必要ありません。これらのタスクを使用していない場合は、プリインストールされたモジュールの変更を避けるために、パイプラインをAzure PowerShellタスクの使用に切り替えてください。
注意事項
これらのアップデートは、セルフホスト型のエージェントで動作するパイプラインには影響しません。
リポジトリを無効にして、ユーザーがそのコンテンツにアクセスできないようにしたいという要望がよく寄せられます。たとえば、次のような場合に実行したいと思うでしょう。
- リポジトリに秘密情報があることを発見した。
- サードパーティのスキャンツールで、リポジトリーにコンプライアンス違反が存在していることが判明した。
このような場合、問題の解決に向けて作業を行う間、一時的にリポジトリを無効にできます。今回のアップデートでは、Delete repository権限を持っていれば、リポジトリーを無効にできます。レポを無効にすることで、以下のことが可能になります。
- レポのリストにそのレポを表示できる
- レポの内容の読み取りができない
- レポの内容の更新ができない
- Azure Repos UI でレポにアクセスしようとすると、レポが無効になったというメッセージが表示される
必要な緩和措置が取られた後、Delete repository権限を持つユーザーは、リポジトリを再び有効にできます。リポジトリを無効または有効にするには、Project SettingsでRepositoriesを選択し、特定のリポジトリを選択します。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Vijay Machiraju