kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure DevOpsへ機能要望のTIPS

これはAzure DevOpsアドベントカレンダー4日目の記事です。

qiita.com

Azure DevOpsへのバグ報告および、機能要望はDeveloper Communityでできます。Visual StudioやAzure DevOpsの報告からでもいけるのでおなじみでしょう。クラウドサービスオンプレミスで入り口が違うのでご注意を。

バグ報告は割と早く返事が返ってきます。メールで来るんですが、通知をうまく設定していないと自分のバグ報告すらうまくわからなくなります。MSの人割と返事早いので、時差を見越しておけば大体いい感じで返事が来てるようです。

要望ですが、彼らも無限のリソースを持っているわけではないので、優先度に応じて決められるようです。はっきりしたことは公開されていませんが、おおむねこんな基準のようです。

  1. up voteが多い
  2. コメントでしっかり必要なケースが書かれている
  3. 90日以内に反応がある

注意すべきは3でコメントやup voteが90日以上ない場合、自動的にクローズされます。参考例として、Wikiの更新通知をTeamsに送りたいという要望です。

As a result, we depend on the community to validate the request via votes and comments. Suggestions that the community doesn't prioritize, we close out in order to maintain a manageable list of suggestions. It is our policy to close suggestions that are inactive in the community based on no change to customer comments or votes in the last 90+ days. We love your enthusiasm for our product and hope you will continue submitting ideas for the community to validate.

とまぁ、no change to customer comments or votes in the last 90+ daysと書かれていて、「90日以上モニタリングしたけど、up voteもコメントもなかったので閉じる」というコメントとともにクローズされています。これは開発ボリュームが大きかったということもあるようですが。通常はfollowしておいて、メール通知ということになるのでしょう。

余談ですが、Wikiの更新をTeamsに流すのはProject Wikiではできないのですが、Code WIki(Azure Reposから作るWiki)ではGitのコミットフックがサポートされているので、更新通知をTeamsへ流したいWikiであれば、Code Wikiでつくればいいようです。Twitterで補足をいただきました。ありがとうございます。

Azureのサブドメイン乗っ取りを防ぐための検証スクリプトを実行してみる

Azureからこんなメールが来ていて何事かと思いました。

Important security information regarding your organization's subdomain(s)

This email notification has been sent to each Global Administrator(s) and/or Technical Contact of your Azure Active Directory tenant. 

Our security team has identified specific Domain Name System (DNS) subdomains that belong to your organization's Azure Active Directory tenant, that have been left dangling (not mapped to an active Azure resource). We want you to be aware of this issue, as dangling DNS entries can pose a security risk. 

Summary of Issue: 
Dangling DNS starts when custom DNS from your domain's DNS zone is mapped to a DNS CNAME record of an Azure resource that is no longer provisioned, leaving the associated domain "dangling". This dangling DNS entry, also known as a dangling domain, leaves the domain vulnerable to a malicious action known as a subdomain takeover. When a subdomain takeover occurs, a malicious actor takes control of the domain which was previously associated with your deprovisioned Azure resource. By gaining control, malicious actors can intercept traffic intended for that endpoint and/or offer malicious contraband content from that endpoint. The potential impact may vary depending on the architecture of your application. 

ちょっと前話題になったこの件だと思います。

nakedsecurity.sophos.com

MSのセキュリティブログからも案内が出ています。

msrc-blog.microsoft.com

公式のdocsも出ています。

docs.microsoft.com

難しそうに見えるのですが、要はGitHubからPowerShellをダウンロードして実行して確認しましょう、ということなので、やってみます。

github.com

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/Azure/Azure-Network-Security/master/Cross%20Product/Find%20Dangling%20DNS%20Records/Get-DanglingDnsRecords.ps1" -OutFile "Get-DanglingDnsRecords.ps1"

ダウンロードしたPowerShellをとりあえず実行してみます。実行するときにはGlobal Tenant Admin(テナント全体管理者)権限が必要になります。

 .\Get-DanglingDnsRecords.ps1 -FetchDnsRecordsFromAzureSubscription  

f:id:kkamegawa:20201202144705p:plain

とりあえず大丈夫っぽい。実行するときは現在の既定のサインイン情報を使うようで、実行時認証指定できない…のかな?おそらく事前にlogin-azaccountしていればいいのかなと思います。ぜひチェックしておきましょう。

Azure DevOps 2020/11/12の更新

Azure DevOps Sprint 178リリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回の目玉は拡張機能ではなく、コア機能の一部として取り込まれたDelivery Plans 2.0プレビューです。この拡張機能は本当にどのorganizationにも入れてほしくておすすめしているのですが、なかなか知られていませんでした。

コア機能になったことでもっと知られるようになると思います。2020年末までには2.0正式版として公開するそうですが、感謝祭が終わって、クリスマス休暇に入る前(大体12月中旬から仕事しなくなる)に終わらせられるんでしょうかね…アドベントカレンダーのいいネタになりそうですが。

qiita.com

地味に嬉しい強化として、Work Itemの一覧からRemovedステータスのものが消えてくれるようになるそうです。これ前から邪魔だったんですよね。ようやくと言う感じですがやらないよりはいいですね。

Classic エディターのView YAMLがExport YAMLに変わるそうです。今までは微妙に使えない(多少直さないといけなかった)やつだったのですが、完全にYAMLエディターで書くものと同じになるそうで、少なくともビルドに関しては移行しやすくなったんじゃないかなと思います。Release側も作らないといけないですね。

Test Plansの新しいページが一般提供開始です。今まではプレビューであることを示す*付きとふたつあったはずですが、なくなります。

ではまた三週間後。多分年内最後の更新になりそうな気がします。

Translate to Japanese to Azure DevOps release not…

Azure Pipelines - Multi Stage Pipeline Part4動画公開

いろいろやったり、NGテイクをうまくつなげて見せようとしたらますます時間がかかってしまいました…


Azure Pipelines Multistage part4

今回は並列デプロイとEnvironmentsを使ったデプロイの承認について解説しています。これでMulti-Stageパイプラインの動画でやりたい基本的なことは一応やったので、次はK8s(AKS)をちょっと勉強してやってみようかなと思います。