このスプリントでは、パーソナルアクセストークン(PAT)の範囲と寿命を制限する新しいポリシーを追加しました。また、Team Foundation Version Control(TFVC)のWindows Shell拡張機能を更新し、Visual Studio 2019をサポートしました。
詳細については、以下の機能説明を確認してください。
- Azure ADのテナントポリシーでパーソナルアクセストークン(PAT)の参照範囲と寿命の定義ができるようになりました
- IPv6トラフィックに対して条件付きアクセスポリシーの設定ができるようになりました
パーソナルアクセストークン(PAT)を使用すると、Azure DevOpsに対して認証を行い、ツールやサービスと統合することが容易になります。しかし、漏洩したトークンは、Azure DevOpsのアカウントやデータを危険にさらし、アプリケーションやサービスを危険にさらす可能性があります。
管理者が必要なコントロールができないために、漏洩したPATがもたらす脅威の影響を制限できないというフィードバックをいただきました。これらのフィードバックに基づいて、OrganizationのAzure DevOpsパーソナルアクセストークン(PAT)の範囲と寿命を制限するために使用できる新しいポリシーセットを追加しました。その仕組みは次のとおりです。
Azure Active DirectoryのAzure DevOps管理者ロールに割り当てられたユーザーは、Azure ADにリンクされているAzure DevOps Organzationの設定で、Azure Active Directoryタブに移動できます。
管理者が可能な点を列挙します。
- グローバル・パーソナル・アクセス・トークン(ユーザがアクセスできるすべてのAzure DevOps organizationで機能するトークン)の作成を制限する
- フルスコープのパーソナルアクセストークンの作成の制限
- 新しいパーソナル・アクセス・トークンの最大有効期間の設定
これらのポリシーは、Azure ADテナントにリンクされたAzure DevOps organizationのためにユーザーが作成したすべての新しいPATに適用されます。各ポリシーには、そのポリシーから除外される必要があるユーザーやグループのための許可リストがあります。許可リストに登録されたユーザーやグループは、ポリシーの設定を管理するためのアクセス権はありません。
これらのポリシーは、新しいPATにのみ適用され、すでに作成されて使用されている既存のPATには影響しません。ただし、ポリシーを有効にした後、ポリシーに準拠していない既存のPATに関しては、ポリシーに準拠するように変更してから、更新する必要があります。
条件付きアクセスポリシー(CAP)のサポートを拡張し、IPv6フェンシングポリシーを含めることになりました。IPv6アドレスからデバイス上のAzure DevOpsリソースにアクセスする人が増えていることから、IPv6トラフィックからのアクセスを含め、あらゆるIPアドレスからのアクセスを許可・削除できるようにしたいと考えています。
クラシックリリースには、実行されたビルド結果を自動的に保持する機能がありました。これはクラシックリリースと YAML パイプラインとの間のギャップの 1 つであり、YAML への移行を躊躇する人もいました。今回のリリースでは、このギャップに対処しました。
リリースを表現するためにマルチステージのYAMLパイプラインを作成し、その中の別のYAMLパイプラインをリソースとして参照できます。これを行うと、Azure Pipelinesは、リリースパイプラインが保持されている限り、リソースパイプラインを自動的に保持します。リリースパイプラインが削除されると、リソースパイプラインのリースが解除され、独自の保持ポリシーに従います。
YAMLパイプラインを作成する際に、存在しないEnvironementを参照すると、Azure Pipelinesは自動的にEnvironmentを作成します。この自動作成は、ユーザーコンテキストまたはシステムコンテキストのいずれかで発生します。以下のフローでは、Azure Pipelines は操作を実行するユーザーを認識しています。
- Azure Pipelines Web エクスペリエンスの YAML パイプライン作成ウィザードを使用して、まだ作成されていないenvironmentを参照する。
- Azure Pipelines Web エディターを使用して YAML ファイルを更新し、存在しないenvironmentへの参照を追加した後にパイプラインを保存する。
- 別の外部コードエディタを使用してYAMLファイルを更新し、Azure Pipelines Webインターフェイスを使用して手動で新しい実行を開始する。
上記の各ケースでは、Azure Pipelinesは、操作を行うユーザーを明確に認識しています。したがって、environmentを作成し、そのenvironmentの管理者ロールにユーザーを追加します。このユーザーは、environmentを管理するためのすべての権限および、environmentを管理するためのさまざまなロールに他のユーザーを含めるための権限を持っています。次のフローでは、Azure Pipelinesは、environmentを作成するユーザーに関する情報を持っていません。別の外部コードエディタを使用してYAMLファイルを更新し、存在しないenvironmentへの参照を追加し、継続的インテグレーションのパイプラインを実行します。このケースでは、Azure Pipelinesは実行されるユーザーを認識できません。以前は、プロジェクトのコントリビューター全員をenvironmentsの管理者ロールに追加することで、このケースを処理していました。その後、プロジェクトのメンバーは誰でもこれらの権限を変更し、他の人がenvironmentsにアクセスできないようにすることができました。
プロジェクトのメンバー全員にenvironmentsの管理者権限を付与することについて、お客様からご意見をいただきました。ご意見を伺っていると、操作を行うユーザーが誰であるかが明確でない場合、environmentを自動作成するべきではないという声がありました。今回のリリースでは、environmentの自動作成方法を変更しました。
- 今後、パイプラインを実行しても、environmentが存在しない場合や、ユーザーのコンテキストがわからない場合は、environmentを自動的に作成しません。このような場合、パイプラインは
Environment not found
というエラーで失敗します。パイプラインで使用する前に、適切なセキュリティとチェックの構成でenvironmentを事前に作成する必要があります。 - ユーザーのコンテキストがわかっているパイプラインでは、これまでと同じようにenvironmentが自動作成されます。
- 最後に、environmentを自動作成する機能は、Azure Pipelineを使い始める際のプロセスを簡素化するために追加されただけであることに注意してください。これはテストシナリオ用で、本番シナリオ用ではありません。本番環境は、常に適切なパーミッションとチェックで事前に作成し、パイプラインで使用する必要があります。
お客様からのフィードバックに基づき、ワークフローを改善するため、ビルドパイプラインをナビゲートする際に表示されるタスク/パイプラインのインサイトダイアログボックスが削除されました。必要な情報を入手するためのパイプライン分析機能は引き続き利用できます。
前バージョンのTFVC Windows Shell拡張機能は、Visual Studio 2017がインストールされているコンピュータでのみ動作しました。
このツールの新バージョンをリリースし、Visual Studio 2019に対応しました。この拡張機能は、Windows Explorerと一般的なファイルダイアログの統合を提供します。この統合により、Visual StudioやTeam Foundationのコマンドラインツールを実行することなく、多くのソースコントロール操作が可能です。
注意事項
ここで議論されている機能は今後二~三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Vijay Machiraju