セキュリティ管理の強化
この更新プログラムでは、プロジェクト全体またはorganizationの Advanced Security を有効または無効にするオプションが追加されました。 新しく作成されたリポジトリまたはプロジェクトに対して Advanced Security を自動的に有効にすることもできます。
Azure Pipelines では、フォークされた GitHub リポジトリから構築された pull request のセキュリティを向上させるための一元化された制御を追加しました。
これらの機能の詳細については、リリース ノートを参照してください。
全般
Azure Pipelines
Azure Repos
Azure Artifacts
全般
Advanced Security のプロジェクトレベルとorganizationレベルの有効化
これで、プロジェクト全体またはorganizationの Advanced Security を有効または無効にできるようになりました。 有効化前にコミッター数を表示する新しい追加機能と組み合わせて、プロジェクトまたはorganizationレベルで [すべて有効にする] を選択すると、課金対象となる新しいアクティブなコミッターの数の見積もりが表示されます。 また、それぞれのプロジェクトまたはorganizationで新しく作成されたリポジトリまたはプロジェクトに対して Advanced Security を自動的に有効にすることもできます。 この設定で有効になっているリポジトリには、シークレット リポジトリのスキャンとプッシュ保護がアクティブになります。
プロジェクト レベルの有効化:
組織レベルの有効化:
Advanced Security の有効化中の推定コミッター数
Advanced Security オンボード エクスペリエンスの一環として、特定のリポジトリ、プロジェクト、またはorganizationの Advanced Security を有効にした結果、追加されたアクティブなコミッターの数の見積もりを確認できるようになりました。 この数は近似値であり、提供された見積もりと、有効化後の課金に対して報告される内容との間に若干の不一致が見える場合があります。 この見積もりは、このプロセスが近日公開される予定である追加のドキュメントを使用して API を使用して取得することもできます。
Azure Pipelines
承認とチェックがタイムアウトになったときにステージを再試行する
承認とチェックがタイムアウトすると、所属するステージはスキップされます。 スキップされたステージに依存するステージもスキップされます。
承認とチェックのタイムアウト時にステージを再試行できるようになりました。以前は、承認がタイムアウトした場合にのみ可能でした。
すべての環境の管理者ロール
YAML パイプライン内の環境は、アプリケーションをデプロイするコンピューティング リソース (AKS クラスターや VM のセットなど) を表します。 これらは、デプロイのセキュリティ制御と追跡可能性を提供します。
環境の管理は非常に困難な場合があります。 これは、環境が作成されると、環境を作成するユーザーが自動的に唯一の管理者になるためです。 たとえば、すべての環境の承認とチェックを一元的に管理する場合は、すべての環境管理者に特定のユーザーまたはグループを管理者として追加するよう依頼し、REST API を使用してチェックを構成する必要がありました。 この方法は面倒でエラーが発生しやすく、新しい環境が追加されたときにスケーリングされません。
このスプリントでは、環境ハブ レベルで 管理者ロール を追加しました。 これにより、環境はサービス接続またはエージェント プールと同等になります。 管理者ロールをユーザーまたはグループに割り当てるには、既に環境ハブ管理者またはorganization所有者である必要があります。
この管理者ロールを持つユーザーは、アクセス許可の管理、管理、表示、および任意の環境の使用を行うことができます。 これには、すべてのパイプラインへの環境の開放が含まれます。
環境ハブ レベルでユーザー管理者ロールを付与すると、既存のすべての環境と将来の環境の管理者になります。
フォークされた GitHub リポジトリから PR を構築するための一元的な制御
GitHub からパブリック リポジトリをビルドする場合は、フォーク ビルドに対する態度を検討する必要があります。 フォークは組織外から来るので、特に危険です。
GitHub リポジトリとリポジトリ保護を構築する方法に関する推奨事項を確認することで、GitHub パブリック リポジトリを構築するパイプラインのセキュリティを向上させることができます。 残念ながら、多数のパイプラインを管理し、ベスト プラクティスへの準拠を確保するには、かなりの労力が必要になる場合があります。
パイプラインのセキュリティを強化するために、パイプラインがフォークされた GitHub リポジトリから PR を構築する方法を定義するためのorganizationレベルの制御が追加されました。 新しい設定は、フォークされた GitHub リポジトリからの pull request のビルドを制限するという名前で、organizationおよびプロジェクト レベルで動作します。
organization レベルの設定では、プロジェクトで使用できる設定が制限され、プロジェクト レベルの設定によって、パイプラインで使用できる設定が制限されます。
トグルがorganizationレベルでどのように機能するかを見てみましょう。 新しいコントロールは既定でオフになっているため、設定は汎用的に適用されません。
トグルを有効にすると、フォークされた GitHub リポジトリからの PR のビルドを無効にすることができます。 つまり、このような PR の作成時にパイプラインは実行されません。
[フォークされたリポジトリからの pull requests を安全にビルドする] オプションを選択すると、すべてのパイプライン (organization全体) で、フォークされたリポジトリの PR のビルドでシークレットを使用できないようにしたり、これらのビルドに通常のビルドと同じアクセス許可を付与したり、PR コメントによってトリガーする必要があります。 プロジェクトは引き続き、パイプラインでこのような PR のビルドを許可 しないことを 決定できます。
[カスタマイズ] オプションを選択すると、パイプライン設定を制限する方法を定義できます。 たとえば、PR がチーム以外のメンバーと非共同作成者に属している場合に、フォークされた GitHub リポジトリから PR を構築するために、すべてのパイプラインにコメントが必要であることを確認できます。 ただし、そのようなビルドでシークレットを使用できるようにすることもできます。 プロジェクトでは、パイプラインでこのような PR をビルドしたり、安全にビルドしたり、organization レベルで指定された制限の厳しい設定を許可したりすることはできません。
Azure Repos
ユーザーが自分の変更を承認できないようにする新しい "ブランチ ポリシー"
ユーザーが承認する変更に関する制御を改善し、より厳格な規制/コンプライアンス要件に一致させるために、明示的に許可されていない限り、ユーザーが自分の変更を承認できないようにするオプションが用意されています。
ブランチ ポリシーを管理する機能を持つユーザーは、[新しい変更がプッシュされたとき] の下で、新しく追加されたオプション "イテレーションごとに少なくとも 1 つの承認を要求する" を切り替えることができるようになりました。 このオプションを選択すると、最後のソース ブランチの変更に対して少なくとも 1 つの承認投票が必要になります。 ユーザーの承認は、そのユーザーによってプッシュされた以前の未承認のイテレーションにはカウントされません。 その結果、最後のイテレーションに対する追加の承認は、別のユーザーが行う必要があります。
次の図は、ユーザー A によって作成された pull request と、ユーザー B、C、A again、C によってその pull request に対して行われた追加の 4 つのコミット (イテレーション) を示しています。2 回目のイテレーション (ユーザー B によるコミット) が完了した後、ユーザー C はそのことを承認しました。 その時点で、ユーザー A の最初のコミット (pull request が作成されたとき) の承認が暗黙的に行われ、新しく導入されたポリシーは成功します。 5 回目のイテレーション (ユーザー C の最後のコミット) の後、承認はユーザー A によって行われました。これは、ユーザー C によって行われた以前のコミットに対する承認を暗黙的に示していますが、4 回目のイテレーションでユーザー A によって行われた 2 番目のコミットの承認を意味するものではありません。 新しく導入されたポリシーを成功させるには、承認されていないイテレーション 4 は、ユーザー B、C、または pull request に変更を加えなかった他のユーザーからの承認によって承認される必要があります。
Azure Artifacts
Cargo Crates の Azure Artifacts サポートの概要 (パブリック プレビュー)
Azure Artifacts で Cargo クレートのネイティブ サポートが提供されるようになりました。 このサポートには、アップストリーム ソースとして使用できる crates.io に加えて、既存のプロトコルに関する機能パリティが含まれます。 Rust 開発者とチームは、Azure の堅牢なインフラストラクチャを使用し、使い慣れた Azure DevOps 環境を維持しながら、Cargo クレートをシームレスに使用、発行、管理、共有できるようになりました。
プレビューにはサインアップは必要ありません。まず、Azure DevOps プロジェクトに移動し、[成果物] を選択し、Rust プロジェクトを Azure Artifacts フィードに接続する手順に従います。
次の手順
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に進み、見てみましょう。
フィードバックの提供方法
これらの機能についてご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
Silviu Andrica