さっしーの試してみるか3: 1月 2022

2022年1月30日日曜日

Windows Server ＆ Cloud User Group Japan 第27回勉強会資料「AKS on Azure Stack HCI/Windows Serverのデプロイ」のセッション動画を公開します。

※冒頭の録画を補完しているため、途中までスライドのみの映像となります。

Azure Policy support for Azure Site Recovery だそうです

Generally available: Azure Policy support for Azure Site Recovery

という記事を見つけました。

Azure Site Recovery 用の Azure Policy というわけですね。Azure Policy から Site Recover だけをフィルターしたところ、現状下記のポリシーがありました。（ちなみにイニシアティブは無し）

[プレビュー]: Recovery Services コンテナーではプライベートリンクを使用する必要がある
[プレビュー]: プライベート DNS ゾーンを使用するよう Azure Recovery Services コンテナーを構成する
[プレビュー]: プライベートエンドポイントを Azure Recovery Services コンテナーに構成する

現状は、プライベートリンクやプライベート DNS ゾーンの使用を強制するためのポリシーが用意されていました。今後、増えていくかもしれませんね。

システムイベントログにイベントソース Microsoft-Windows-Kerberos-Key-Distribution-Center、イベントID 35 と 37 が記録される

CVE-2021-42287 で追加されたイベントメッセージ ID 35 , 37 と脆弱性対応の流れについて

をご存知でしょうか。

上記記事の通り、2021年11月に脆弱性対策としてリリースされたセキュリティ更新プログラムをインストールすると、表示されるイベントです。

手元の環境でも発生しているか遡って確認したところ、イベントID 37がありました。

このイベントの意図するところを、CVE-2021-42287 で追加されたイベントメッセージ ID 35 , 37 と脆弱性対応の流れについてから引用します。

CVE-2021-42287 の脆弱性対応では、ドメインコントローラーがクライアントに Kerberos Ticket-Granting Tickets (TGT) を発行する際に、TGT の PAC フィールドに "要求元" の情報を追加するようになりました。その後、クライアントが TGT を使ってドメインコントローラーへサービスチケットを要求した際、クライアントから受け取った TGT の "要求元" 情報を検証する動作となっております。
イベントメッセージ ID 35, 37 は、この検証を行った際、TGT に “要求元” などの情報が含まれていなかった場合に記録されるものとなります。そのため、すべてのドメインコントローラーに 2021 年 11 月の更新プログラムを適用した後、特に 1 週間ほどは、クライアントに残存している古い TGT の影響で頻繁にイベントメッセージが記録される場合がございますが、これらのイベントメッセージが記録されていたとしても、ドメインコントローラーが CVE-2021-42287 の “強制モード” に移行しない限り、直ちに問題になることはございません。
ただし、CVE-2021-42287 の対応方針として、2022 年 7 月 12 日リリース予定の更新プログラムで “強制モード” に移行する予定となります。”強制モード” に移行すると、上記イベントメッセージが記録されている TGT はすべて拒否される動作となり、Kerberos 認証に失敗することが想定されます。

TGTに要求元などの情報が含まれていない場合を検出しているとのこと。が、大事なことは上記で赤く色づけした箇所です。TGTに要求元などの情報が含まれていない場合、そのTGTは拒否される、すなわちリソースアクセスなどが拒否されてしまうと考えられます。

2022年7月12日までで、どのような段階的対応となるか、CVE-2021-42287 で追加されたイベントメッセージ ID 35 , 37 と脆弱性対応の流れについての内容を下記へ引用しますので、ご参考になさってください。

[2] 本脆弱性への対処 ( 段階的な展開 )
本脆弱性の段階的な展開については、以下の 3 フェーズで実施される予定です。
1) 2021 年 11 月 9 日: 初期展開フェーズ
このフェーズでは、既定で PacRequestorEnforcement レジストリが “1” と同等の動作となり、PAC に “要求元” が追加されます。
“要求元” が存在しない TGT についても認証を行うことが可能なため、通常、認証に失敗するといった影響はございません。
　※ PacRequestorEnforcement レジストリは既定で存在しません。
　※ 2021 年 11 月 9 日時点で、レジストリが存在しない場合の動作は、”1” と同等の動作になります。
2) 2022 年 4 月 12 日: 第 2 展開フェーズ
このフェーズでは、PacRequestorEnforcement レジストリの 0 が削除されます。この更新プログラムをインストール後、PacRequestorEnforcement を 0 に設定しても、 1 に設定した際と同じ動作になります。
　※ PacRequestorEnforcement を 0 に設定していない環境では、このフェーズは不要です。
3) 2022 年 7 月 12 日: 強制フェーズ
PacRequestorEnforcement のレジストリキーが無効化され、強制的に PacRequestorEnforcement = 2 の動作となります。
強制フェーズでは、以下のドメインコントローラーと互換性が無くなります。
・ 2021 年 11 月 9 日以降の更新プログラムをインストールしなかったドメインコントローラー
・ 2021 年 11 月 9 日以降の更新プログラムをインストールしたが、PacRequestorEnforcement が 0 に設定されており、且つ、2021 年 4 月 12 日の更新プログラムを適用していないドメインコントローラー
次のドメインコントローラーと互換性があります。
・ 2022 年 7 月 12 日以降の更新プログラムをインストールしたドメインコントローラー
・ 2021 年 11 月 9 日以降の更新プログラムをインストールし、PacRequestorEnforcement が 1 または 2 を持つドメインコントローラー

2022年1月22日土曜日

Windows Server ＆ Cloud User Group Japan 第27回勉強会資料「AKS on Azure Stack HCI/Windows Serverのデプロイ」を公開します。

AKS on Azure Stack HCI/Windows Serverのデプロイ _ Deploying AKS on Azure Stack HCI/Windows Server

2022年1月14日金曜日

AKS ランタイム on Azure Stack HCI/Windows Server の Kubernetes クラスターを Azure Monitor Container Insights から外します

Kubernetes クラスターを Azure Monitor に登録する

の続き。Azure Monitor から Kubernetes クラスターを外したいと考えました。例えば、ミスのリカバリーなどに利用できると考えてます。

まず確認したのが、下記です。

Azure Arc 対応 Kubernetes 上で監視を停止する方法

もろもろの準備を終えて、

.\disable-monitoring.ps1 -clusterResourceId $azureArcClusterResourceId -kubeContext $kubeContext

を実行しました。

エラーが発生しました。。。何回か試しましたが、やはり同じ。helm と書いてあるので、これは何だと思い、普通にコマンド実行してみました。

helm は、標準コマンドじゃなかったですね。。。Kubernetes 用のパッケージ導入を司るものですね。ということで、
https://github.com/helm/helm/releases

からダウンロードして、環境変数 PATH が通るところに配置しました。

再実行。

helm chart で検出される Azure Monitor 用の名前がないし。

以上、この方法で、Azure Monitor から Kubernetes クラスターを外すことはできないとわかりました。

ほかに方法はないのかと、あれこれあたってみましたよ。

そしたら、拡張機能にそれらしいものがあった。

そういえば、Azure Monitor にオンボードした方法

Kubernetes クラスターを Azure Monitor に登録する

に書いていた

Azure Arc 対応 Kubernetes クラスター用の Azure Monitor Container - Azure Arc 対応 Kubernetes リソースブレードからのオンボード

で、こういう記述があります。

[構成] ボタンを選択して、Azure Monitor Container Insights クラスター拡張機能をデプロイします。

ということで、ビンゴのようです。では、[アンインストール]をクリックします。

確認のダイアログがでますので、[はい]をクリックします。

しばらく待つと拡張機能がアンインストールされました。

Azure Monitor から Kubernetes クラスターが一つ外れました。

AKS 自体は、Azure Monitor に残してありますけどね。

ちなみに、Kubernetes クラスターを Azure Monitor Container Insights から外すための az CLI コマンドは、下記にあります。必要に応じ、ご確認いただけますと幸いです。

拡張機能インスタンスを削除する

2022年1月12日水曜日

Azure Backup - Automation updates - 2021 だそうです

Azure Backup - Automation updates - 2021

ということなので上記から、引用/抜粋してみます。

General Availability of Recovery Services CLI
コマンドラインで操作できるようになりますねー。
PS/CLI support for Backup Vault workloads
Azure Databases for PostgreSQL Server, Azure Blobs, Azure Disks といったような Backup vaults (日本だとバックアップコンテナーと呼んでいるかな）に対して、PowerShell やコマンドラインが使えるってことですね。
Terraform support for Backup vault workloads
PostgreSQL DB backup、 Blob backup と Disk backup で Terraform モジュールが使えます。
Bicep templates for Azure Backup
”Bicepは、Azureリソースをデプロイするために宣言的な構文を使用するDSL（domain-specific language）です。”ということなんだそうで。
What is Bicep? に概要記事があります。
Azure VM backup、Blob backup と Disk backup で使える Bicep テンプレートが使えるようです。
PS/CLI support for new features
Archive storage, User-assigned identity for CMK、MSI authentication for managed disk restoreといった新機能で、PowerShell やコマンドラインが使えるってことですね。

PowerShell やコマンドラインが使えるなら、Automation の一助になりますね。
まず、コマンドラインインタフェースから、別途調べてみようかなぁ。

2022年1月3日月曜日

Kubernetes クラスターを Azure Monitor に登録する

Azure Stack HCI/S2D クラスターにある、Kubernetes クラスターを Azure Monitor に登録します。

前提条件を確認しましょう。

Azure Arc 対応 Kubernetes クラスター用の Azure Monitor Container - 前提条件

登録方法は、

に載っている通り。上記1番に沿ってみます。

Azure Portal から Kubernetes クラスター開いて、[監視]→[分析情報]をクリックします。

[Azure Monitor の構成]をクリックし、[Azure Log Analytics ワークスペース]をプルダウンメニューから選択して、[構成]をクリックします。
※前提条件に、Azure Log Analytics ワークスペースを指定する旨、記載があります。Azure Log Analytics ワークスペースがない場合は、事前作成しておきましょう。