今回の更新より、プロジェクトまたはOrganization全体のAdvanced Securityを有効または無効にするオプションが追加されました。また、新しく作成されたリポジトリやプロジェクトのAdvanced Securityを自動的に有効にすることもできます。
Azure Pipelines では、フォークされた GitHub リポジトリからビルドされたPull Requestのセキュリティを向上させるための集中管理機能が追加されました。
これらの機能の詳細については、リリースノートをご覧ください。
- Advanced SecurityをProjectやOrganization単位で有効化できるようになりました
- Advanced Securityを有効にした時のコミッター数の概算見積もりが取得できるようになります
- 承認やチェックがタイムアウトした場合、対象ステージが再実行されます
- すべてのEnvironmentsが管理可能なAdministrator roleを追加しました
- フォークされたGitHub reposからのPull Requestでのビルド制御を一括管理できるようになりました
プロジェクトまたはOrganization全体でAdvanced Securityを有効または無効にできるようになりました。有効にする前にコミッター数を表示する機能が追加されたことに伴い、プロジェクトまたはOrganizationレベルで"Enable all"を選択すると、課金対象となる新しいアクティブなコミッター数の見積もりが表示されます。また、プロジェクトやOrganizationの下に新しく作成されたリポジトリやプロジェクトに対して、Advanced Securityを自動的に有効にすることもできます。この設定で有効になったリポジトリは、secret scanningやpush protectionが有効になります。
プロジェクトレベルで有効化する場合:
Organizationレベルで有効化する場合:
Advanced Securityオンボーディングエクスペリエンスの一環として、特定のリポジトリ、プロジェクト、またはOrganizationでAdvanced Securityを有効にした結果、アクティブなコミッターが何人追加されたかの概算を確認できるようになりました。このカウントは概算であり、提供された概算と有効化後に請求のために報告されるものとの間に若干の相違が見られるかもしれません。この見積もりはAPI経由で取得することもでき、このプロセスを説明する追加ドキュメントも近日公開予定です。
承認やチェックがタイムアウトすると、対象のステージはスキップされます。スキップされたステージに依存するステージもスキップされます。
承認やチェックがタイムアウトした場合、対象のステージを再試行できるようになりました。以前は、承認がタイムアウトした場合のみ可能でした。
YAML パイプラインのEnvironmentsはAKSクラスターや複数のVMに対するデプロイのセキュリティコントロールとトレーサビリティを提供します。
Enviornmentsの管理は非常に難しいです。Enviornmentを作成すると、作成者が自動的に唯一の管理者になるからです。例えば、すべてのEnvironmentに対する承認とチェックを一元的に管理したい場合、すべてのEnviornments管理者に特定のユーザーやグループを管理者として追加してもらい、REST APIを使ってチェックを設定しなければなりませんでした。このアプローチは面倒で、エラーが発生しやすく、新しいEnviornmentsが追加されたときにスケールしないという問題があります。
このスプリントでは、environments-hub レベルのAdministrator Roleを追加しました。これにより、Enviornmentsはサービス接続やエージェントプールと同等になります。管理者ロールをユーザーやグループに割り当てるには、すでにenvironments-hubの管理者またはOrganizationの所有者である必要があります。
このAdministrator Roleを持つユーザーは、あらゆるEnviornmentsの権限管理、管理、表示、使用ができます。これには、すべてのパイプラインにEnviornmentsを開放することも含まれます。
environments-hubレベルでユーザーにAdministrator Roleを付与すると、そのユーザーはすべての既存Enviornmentsと将来のEnviornmentsのAdministratorになります。
GitHubからパブリックリポジトリをビルドする場合は、フォークビルドに対するスタンスを考慮する必要があります。フォークビルドは特に危険です。
GitHubパブリックリポジトリをビルドするパイプラインのセキュリティを向上させるには、GitHub リポジトリのビルド方法とリポジトリの保護に関する推奨事項をご覧ください。残念ながら、多数のパイプラインを管理し、ベストプラクティスの遵守を徹底するには、かなりの労力が必要になります。
パイプラインのセキュリティを強化するために、OrganizationレベルでパイプラインがフォークしたGitHubリポジトリからPull Requestをビルドする方法を定義する制御方法を追加しました。新しい設定は Limit building pull requests from forked GitHub repositories と名付けられ、Organizationレベルとプロジェクトレベルで有効になっています。
Organizationレベルの設定はプロジェクトで設定可能な項目を制限し、プロジェクトレベルの設定はパイプラインでの設定を制限します。
Organizationレベルでのトグルの仕組みを見てみましょう。新しいコントロールはデフォルトでオフになっているため、どの設定もプロジェクトに適用されません。
このトグルをオンにすると、フォークしたGitHubリポジトリからのPRのビルドを無効にします。つまり、Pull Requestが作成されたときにパイプラインは実行されません。
Securely build pull requests from forked repositoriesオプションを選択すると、Organization内のすべてのパイプラインは、フォークされたリポジトリからのPull Requestのビルドで秘密情報を利用できなくなり、これらのビルドに通常のビルドと同じ権限を持たせることができなくなります。プロジェクトにおいて、このようなPull Requestのビルドをパイプラインに許可しないという状況を強制できます。
Customizeオプションを選択すると、パイプラインの設定を制限する方法を定義できます。たとえば、フォークしたGitHubリポジトリからPull Requestをビルドする際に、すべてのパイプラインでコメントを必須にできます。そのうえ、そのようなビルドでシークレットを利用可能にもできます。プロジェクトは、そのようなPull Requestのビルドをパイプラインに許可しないようにしたり、安全にビルドするようにしたり、Organizationレベルで指定するよりもさらに制限を厳しくできます。
私たちはAzure Artifactsにおいて、Cargo cratesをネイティブサポートできるようになったと発表できることを嬉しく思います。このサポートには、crates.ioがアップストリームソースとして利用可能であることに加え、既存のプロトコルと同等の機能が含まれています。Rust開発者とチームは、Azureの堅牢なインフラストラクチャを使用し、使い慣れたAzure DevOps環境にいながら、Cargo cratesをシームレスに利用、公開、管理、共有できるようになりました。
Azure DevOpsプロジェクトに移動してArtifactsを選択し、指示に従ってRustプロジェクトをAzure Artifactsフィードに接続することで開始できます。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Silviu Andrica