本連載では、Kubernetesの利用をスケールさせると遭遇する問題と、Azure Arcによる解決をテーマとしている。今回はAzure Arcが提供する、マルチクラウドKubernetes管理に役立つ機能を具体的に解説する。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
第2回では管理者の抱える課題を踏まえ、エピソードやアーキテクチャの話を交えてAzure Arcのコンセプトや特徴を解説しました。要点は3つです。
今回はKubernetesの管理を主題として、Azure Arcの提供機能や内部構造を具体的に解説していきます。
Azure Arcの提供機能は、管理対象に応じて大きく2つのカテゴリーに分けられます。「Azure Arc Enabled Infrastructure」と、「Azure Arc Enabled Services」です。
Azure Arc Enabled Infrastructureは、Azure Arcの管理対象とする、Azure外のインフラストラクチャーリソースを指します。Azure Resource Managerや付加管理サービスがAzure上のリソースに対して実現している、一貫性のある「ガードレール」を、Azure外に敷設できるわけです。
現在、Azure Arc Enabled Infrastructureの管理対象は、KubernetesクラスターとWindows/Linuxの物理/仮想サーバです。Kubernetesクラスターを管理する機能を「Azure Arc Enabled Kubernetes」と呼び、サーバを管理する機能を「Azure Arc Enabled Servers」と呼んでいます。この記事ではKubernetesクラスター向けの特徴的な機能にフォーカスして紹介します。サポートされる環境など詳細について、また、サーバに関しては、以下のリンク先を参照してください。
Azure Arc Enabled Kubernetes
https://docs.microsoft.com/ja-jp/azure/azure-arc/kubernetes/overview
Azure Arc Enabled Servers
https://docs.microsoft.com/ja-jp/azure/azure-arc/servers/overview
Azure Arcは、整備したガードレールの内側でさまざまなサービスを作り、維持できます。代表的なサービスは、Azure SQL Managed InstancesやAzure PostgreSQL Hyperscaleなどのデータベース、Azure App ServiceやOpen Service Meshなどアプリケーション実行基盤です。
これらのサービスの配布、維持には、Azure側の機能だけでなく、Kubernetesのカスタムリソース、オペレーターなどの仕組みを活用しています。つまりAzure Arc Enabled Kubernetesを前提とした拡張機能、という位置づけです。次回解説しますが、利用可能な拡張機能は以下のリンク先から確認できます。
それでは、今回の主題に入ります。Azure Arc Enabled Kubernetesを有効化し、利用する流れに沿って、特徴的な機能について紹介します。
まずは、KubernetesクラスターをAzure Arcの管理対象にします。Azure Arcへのオンボーディングや接続とも呼ばれる作業です。第2回でも触れた通り、Kubernetesクラスターの作成方式は任意です。利用するクラウドサービスやディストリビューションに合わせ、好きなツールを使ってください。
クイックスタート: 既存の Kubernetes クラスターを Azure Arcに接続する
https://docs.microsoft.com/ja-jp/azure/azure-arc/kubernetes/quickstart-connect-cluster?tabs=azure-cli
オンボーディングの主要な前提条件は、管理対象のクラスターからAzureの各種管理APIエンドポイントに対するHTTPS接続が許可されていることです。方向は送信のみで、受信は不要です。プロキシサーバ経由でも可能です。
前提条件を満たした環境で、kubeconfigのコンテキストを管理対象のKubernetesクラスターにします。そして、Azure CLIの拡張機能である connectedk8s で以下のコマンドを実行します。このコマンドでAzure Arcのベースとなるカスタムリソースとオペレーターを導入します。その結果、Azureに対する認証、状態の通知などAzure Arc Enabled Kubernetesの基礎が整います。
shell az connectedk8s connect --name your-cluster --resource-group your-rg
オンボーディング作業はこれだけです。シンプルですね。
オンボーディングが済んだら、ガードレールを構成する拡張機能を導入します。まずは守りを固めましょう。
ポリシー適用(Azure Policy統合)
第一歩としておすすめなのは、Azure Policy拡張機能です。第2回で紹介した通り、Kubernetesクラスター上での危険な操作を禁止し、監査できます。多様な組み込みポリシーが提供されており、Kubernetesのセキュリティリスクに関する知識が少ない段階から使えるのも利点です。
また、拡張機能の導入を強制できるため、例えば後述するMicrosoft Defender拡張機能の導入を確実にします。Azure Policy拡張機能は、ガードレールの核と呼べるでしょう。
Kubernetes 用の Azure Policy について理解する
https://docs.microsoft.com/ja-jp/azure/governance/policy/concepts/policy-for-kubernetes
Azure Policy の組み込みのポリシー定義 - Kubernetes
https://docs.microsoft.com/ja-jp/azure/governance/policy/samples/built-in-policies#kubernetes
なお、拡張機能の導入も、オンボーディング同様にAzure CLIで行います。Azure Policy拡張機能の導入例を、以下に示します。
shell az k8s-extension create --cluster-type connectedClusters --cluster-name your-cluster --resource-group your-rg --extension-type Microsoft.PolicyInsights --name azurepolicy
以降で紹介する他の拡張機能の導入も、同様のコマンドで行います。
ノードとクラスターの脅威保護(Microsoft Defender統合)
Azure Policyで基本的な保護を行った上で、より広くイベントを収集、分析し、脅威の検出や保護を行いたいケースがあります。例えば、Kubernetesクラスター上で動くCoreDNSの構成改ざんを検出する、などです。このようなニーズには、Microsoft Defender拡張機能が有効です。
Microsoft Defender for Containers の概要
https://docs.microsoft.com/ja-jp/azure/defender-for-cloud/defender-for-containers-introduction?tabs=defender-for-container-arch-arc
Microsoft Defender拡張機能は、MITRE ATTACK matrix for Containersに基づく、60を超える脅威シナリオを検出可能です。そしてシナリオは随時追加されています。現在どのような脅威を検出できるかは、リストを参考にしてください。
コンテナーのアラート - Kubernetes クラスター
https://docs.microsoft.com/ja-jp/azure/defender-for-cloud/alerts-reference#alerts-k8scluster
オンプレミスや複数のクラウドを使い分けるにあたって課題となりがちなのは、管理系操作で利用するネットワークです。特にオンプレミスにおいては、ファイアウォールにインターネットから受信方向の穴は開けたくないでしょう。とはいえ、そのために閉域ネットワークサービスを前提とするのも極端です。
そこでAzure Arcでは、Azureを介した接続を仲介するサービスを提供します。まず、管理対象のクラスターに接続エージェントを導入し、Azure内の接続サービスに対し、送信方向の接続を確立しておきます。そして、kubectlなどkubeconfigファイルを利用した操作をAzure Arcプロキシが受け取り、Azure上のエンドポイント、接続サービスを介し、管理対象クラスターへと転送します。
管理系操作は事故や悪用を防ぐため、厳密に権限管理、監査すべきです。一方で、多くの管理者は、自身の端末に整備してある手になじんだツールを使って生産性を上げたり、トラブル対応を効率的に行ったりしたいと思っています。つまり、いわゆる踏み台サーバを管理者で共有し、制約するアプローチは、そのニーズに反します。KubernetesとAzure Arcが提供する権限管理、監査機能に加え、Azureを介したクラスター接続機能を使うことで、この課題の解決が期待できます。
クラスター接続を使用して、任意の場所から Azure Arc 対応 Kubernetes クラスターにアクセスする
https://docs.microsoft.com/ja-jp/azure/azure-arc/kubernetes/conceptual-cluster-connect
ところで、この節で触れたガバナンス、セキュリティの確立や実践については、筆者がこれまで関わったKubernetes利用プロジェクトの大多数で必要とされ、その実現方式が議論されました。よって、これらはガードレールに求められる代表的な機能と考えてよいでしょう。
Azure Arc Enabled Kubernetesには、ガードレールのように必須ではないものの、利用者によっては有用な拡張機能が他にもあります。それぞれの領域で代替となるサービスや製品、オープンソースソフトウェアは多くありますが、Azure Arcの拡張機能として容易に導入、維持できるのは魅力です。代表的な拡張機能を紹介します。
あるべき状態をGitリポジトリで管理し、実行環境がその構成を常に満たすよう、プルと差分チェック、適用を繰り返す、というコンセプト「GitOps」が注目されています。状態と変更の一元化と可視化、再現性、セキュリティなどの利点があります。
Azure ArcはGitOpsの実現手段として、CNCFプロジェクトであるFluxを拡張機能として提供します。
Azure の GitOps
https://docs.microsoft.com/ja-jp/azure/azure-arc/kubernetes/conceptual-gitops-flux2
現代のアプリケーションは、証明書や鍵、依存サービスへの接続情報などさまざまな秘匿情報を利用します。当然ながらハードコードなど静的な埋め込みは推奨されず、外部から実行時に注入すべきです。従って、それらの秘匿情報を安全に保管し、認証・認可の上で提供し、監査情報を残す「シークレットストア」が求められます。また、アプリケーションは、シークレットストア特有の操作に依存しないのが理想的です。
Azure Arcには、AzureのシークレットストアであるKey Vaultへの透過なアクセスを提供する、Azure Key Vault シークレット プロバイダー拡張機能があります。アプリケーションはAzure Key Vault上の証明書、キー、シークレットに対し、ローカルにマウントしたファイルや環境変数を通じてアクセスできます。
Azure Key Vaultシークレットプロバイダー拡張機能を使用してArcクラスターにシークレットをフェッチする
https://docs.microsoft.com/ja-jp/azure/azure-arc/kubernetes/tutorial-akv-secrets-provider
Kubernetesクラスターとその上で動くアプリケーションの監視には、監視系SaaSやオープンソースなど幅広い選択肢があります。アプリケーション開発者が主体的に選定、利用するケースも増えており、特にその意思を尊重すべき領域と筆者は考えます。ですが、Azure Arcにオンボーディング済みのクラスターであれば、拡張機能によってAzure Monitorとの統合が容易です。検討する価値はあるでしょう。
Azure Arc対応Kubernetesクラスター用の Azure Monitor Container Insights
https://docs.microsoft.com/ja-jp/azure/azure-monitor/containers/container-insights-enable-arc-enabled-clusters?toc=/azure/azure-arc/kubernetes/toc.json
今回は、Azure Arcの提供機能や内部構造を具体的に解説しました。要点を以下にまとめます。
次回は最終回です。Azure Arc Enabled Servicesを解説します。ガードレールにとどまらないAzure Arcの魅力をお伝えします。
Copyright © ITmedia, Inc. All Rights Reserved.