Azure Policy

この記事はシリーズの4番目の記事です。まだほかの記事を読んでない方は先に読むことをお勧めします！ https://cloud.ebisuda.net/2022/02/21/azure-policy%e3%81%a7opsramp%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%99%e3%82%8b-%e3%81%9d%e3%81%ae%ef%bc%91-opsram/ 今回は、「修復タスク」を使って、OpsRampエージェントが入っていないと判断されたVMに対してエージェントを自動インストールさせちゃいます！ …、とはいえ、前回のポリシー適用時に、修復タスクも作成してありますので、全自動です（笑 自動的に、評価され、しばらくすると完了となりました。 どのノードに対して適用されたのかもわかります。Azure Stack HCI OSのノードも対象になっていますね。 ですが、ポリシーへの準拠状況としてはまだ準拠していないものがほとんどです。反映にはそれなりに時間がかかります。のんびりと待ちます。 ここで、1日以上時間をおきました。ですが、結局適用されたのは2台のみでした…。おかしいですね。 適用され、きちんと準拠している状態と出ているサーバーはOpsRampのコンソールからも確認できました。 準拠してくれない原因を調べたところ、例えばVMが停止したままだったり、Azure Arcで接続が切れていたりなどきちんと稼働してAzureと通信が取れていないVMであることがわかりました。Azureポリシーのコンプライアンスの状態の画面からだとパッと見ではそこまでわかりませんね…。 とはいえ、1台づつリソースを簡単に確認することはできます。 この状態では、コンプライアンスに準拠した状態にならないのは当たり前ですね…。 このようなオフラインのままのVMを一括でリストアップするようなことはAzure MonitorやResource Graphあたりを使ってやれば簡単にできそうですね。また別の機会に記事にしたいと思います。 というわけで、100%になっておらずちょっと気持ちが悪いところもありますが、オリジナルのAzure Policyのポリシーを作成し、それを展開することでOpsRampエージェントをVMに導入し、管理しているテナントに紐づけることを自動化することができました。さらに、コンプライアンスの状態も継続的に確認できます。これなら誤ってエージェントをアンインストールしたような状況でも再度エージェントがインストールされますし、管理化に入っていないVMを簡単に追跡できますね。 また、見てきたようにAzure Arcを使ってAzure外のVMも対象にすることができます。今回は触れていませんがAzure LightHouseと連携させて、顧客のテナントに対してポリシーを適用することも可能です。色々と夢がひろがりますね！

この記事はシリーズの3つ目の記事です！前回までの記事を未読の方はそちらを先に読んでいただくことを推奨します！ https://cloud.ebisuda.net/2022/02/21/azure-policy%e3%81%a7opsramp%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%99%e3%82%8b-%e3%81%9d%e3%81%ae%ef%bc%91-opsram/ https://cloud.ebisuda.net/2022/02/22/azure-policy%e3%81%a7opsramp%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%99%e3%82%8b-%e3%81%9d%e3%81%ae2-azure-policy/ では、前回まででAzure Policyを公開できていますのでそれを割り当てていきたいと思います。 ポリシーの割り当て では、テスト的にサブスクリプション全体に対してポリシーを割り当ててエージェントが入っているもの、入っていないものがきちんと可視化されることを確認します。 せっかくですのでAzure Arcのサーバーも対象可能とします。これでAzure内のVMのみならずどこにあるVMでも実機でも対象にすることができます。 修復タスクも実行可能なようにします。ポリシー割り当て自体がマネージドIDを持ち、その権限でVMを修正することになります。素敵な仕組みですね。 反映にはしばらく時間がかかりますので、待ちます。 しばらく時間を置くと、すでに展開済みのVMが準拠していないということが検出されました。 これで、OpsRampエージェントが入っていないVMをすぐに見つける事が可能となりました！とっても便利ですね。 次は、エージェントが入っていないVMに対して修復アクションを実行してエージェントをインストールすることができるようにしていきたいと思います！

この記事は前回の続きです。前回の記事を未読の方は前回の記事から読んでいただくことを推奨します！ https://cloud.ebisuda.net/2022/02/21/azure-policy%e3%81%a7opsramp%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%99%e3%82%8b-%e3%81%9d%e3%81%ae%ef%bc%91-opsram/ ゲスト構成用パッケージを作成する 前回までで動作確認できてますのでゲスト構成用パッケージを作成していきます。 まず、ゲスト構成用のモジュールをインストールします。 I n s t a l l - M o d u l e - N a m e G u e s t C o n f i g u r a t i o n 次に、ゲスト構成パッケージを作成します。 N e w - - - - - N C T F G a o y o u m n p r e e f e c s i e t ' g A C O u u o p r d n s a i f R t t i a i A g m o n u p n d r A S a g e t e t i n / o t I ` n I n P n s a s t c t a k a l a l l g l O e ' p s ` ` R a m p C l i e n t / l o c a l h o s t . m o f ' ` 作成に成功するとZipファイルが生成されます。 ...

以前、AnsibleでのOpsRampエージェントインストールをやりましたが、今回はPowerShell DSCです。 将来的にOpsRampエージェントのインストールをAzure Policyを使って「管理下のVM(Azure上のVMでもオンプレのVMでもすべて)にはOpsRampエージェントをインストールし、その状態を保つ」ということを実現したく、今回はその前準備的な感じです。 DSC自体はマルチプラットフォーム対応ですが、まずはWindowsを対象に進めます。 OpsRampエージェントをhttpsでアクセスできる場所へに配置する 今回はMSI版をダウンロードして利用しようと思います。(※exe版でも同じです) 将来的にAzureからの管理を考えているので、インストーラーはAzure上のストレージアカウントに配置しておきます。 当初SASを生成して利用しようとしましたが、SASだとDSCからきちんとMSIパッケージだと認識してもらえなかったので、直接URLを指定してダウンロードできるように、匿名の読み取りアクセスを許可しました。 このとき、exeにしてしまうと、OpsRampのテナントに接続するための情報も含まれてしまうのでこのやり方をするならMSIパッケージの方が良いですね。 手元のWindowsPCにDSCを適用する ここから先はPowerShellコンソールで操作をします。Windows PowerShellではなくPowerShell Coreでやった方がいいのではと思います。(※これはよくわかっていません。将来的にAzure Policyでマルチプラットフォームを見越しているので、おそらく。でも今回はインストーラーがWindows専用ですから気にしなくていいのかもしれません。) まずモジュールをインストールします。 I # n s D t o a c l s l の - 記 M 事 o で d は u ス l コ e ー プ - 指 N 定 a は m 無 e い で P す S が D 、 s 私 c は R A e l s l o U u s r e c r e s s に 入 - れ S た c 方 o が p よ e い の A で l は l と U 思 s っ e て r い s ま す - V e r b o s e - F o r c e つぎに、PowerShellでConfigurationを定義します。Functionを定義するような感じですね。 ...

Azure環境を利用している際に「任意の場所からの接続」は禁止して、明確に接続元IPアドレスを制限したいというケースが結構あると思います。もちろん全世界に広くWebサイトを公開するような場合はこれに当てはまらないわけですが、検証用途専用のサブスクリプションを作成しているような場合には事故を防ぐために「もしも任意の場所からの接続を許可するNSGのルールを作ろうとした場合にはそれをブロックしたい」というのはよくある要望です。 これはAzure Policyで実現できます。 Azure Policy の概要 - Azure Policy | Microsoft Docs 規定で定義されているポリシーにはこのようなルールは存在しないので、カスタムポリシーを独自に定義する必要があります。 サンプルも参考にしながら、やはりきちんと構造をしっかりと理解して自分で書けるようになってしまうのが急がば回れだと思います。 とりあえず下記が「NSGのルールとして『任意の場所からの接続』の作成を禁止するPolicyのサンプルです。