Azure Kubernetes Service (AKS) でのクラスターのセキュリティとアップグレードに関するベスト プラクティス

適用対象: ✔️ AKS 自動 ✔️ AKS Standard

Azure Kubernetes Service (AKS) でクラスターを管理する際には、ワークロードとデータのセキュリティが重要な考慮事項になります。 論理的な分離を使用してマルチテナント クラスターを実行する場合は、特にリソースとワークロードのアクセスをセキュリティで保護する必要があります。 最新の Kubernetes およびノード OS のセキュリティ更新プログラムを適用することで、攻撃のリスクを最小限に抑えます。

この記事では、AKS クラスターをセキュリティで保護する方法について説明します。 学習内容は次のとおりです:

  • Microsoft Entra ID と Kubernetes のロールベースのアクセス制御 (Kubernetes RBAC) を使用して API サーバー アクセスをセキュリティで保護します。
  • ノード リソースへのコンテナー アクセスをセキュリティで保護する。
  • AKS クラスターを最新の Kubernetes バージョンにアップグレードする。
  • ノードを最新の状態に保ち、セキュリティ パッチを自動的に適用する。

また、コンテナー イメージの管理とポッドのセキュリティに関するベスト プラクティスも参照できます。

AKS クラスター モードのセキュリティ責任

AKS では、 AKS Automatic と AKS Standard の 2 つのクラスター モードがサポートされています。 セキュリティ目標は両方のモードで同じですが、実装の責任は異なります。

AKS Automatic には、サポートされている構成でより多くの構成済みコントロールを含む強化されたベースラインが含まれています。 AKS Standard では、より広範な直接構成制御が提供されるため、ベースラインのセットアップと継続的な運用に対するオペレーターの責任が高くなります。

Area AKS Automatic AKS Standard
クラスターの認証と承認のベースライン サポートされている構成で構成済みのその他の既定値 演算子によって明示的に構成されるのが一般的です
API サーバー ネットワークのセキュリティ強化 サポート対象の構成で、より多くの事前構成されたベースライン動作 演算子による明示的なセキュリティ強化の選択
ポリシーとベースラインのセキュリティ制御 サポートされている構成で構成済みのその他の既定値 明示的なポリシーの有効化とモードの選択
イメージ衛生管理 サポートされている構成で使用可能なベースライン コントロール 明示的な有効化とライフサイクルの所有権
システムノードプールの操作 その他のサービス管理動作 演算子で管理されるその他の動作
所有権のアップグレード その他の管理されたアップグレードの既定値 オペレーターが選択した戦略とロールアウト ガバナンス

脅威保護を有効にする

ベスト プラクティスのガイダンス

Defender for Containers を有効にすると、コンテナーのセキュリティ保護に役立ちます。 Defender for Containers は、クラスター構成を評価し、セキュリティの推奨事項を提供し、脆弱性スキャンを実行し、Kubernetes ノードとクラスターのリアルタイム保護とアラートを提供できます。

このガイダンスは、両方のモードに適用されます。 AKS Automatic が構成済みのセキュリティの既定値を提供する場合でも、脅威保護のオンボードとアラート対応のワークフローは、チームの運用上の責任のままです。

API サーバーとクラスター ノードへのアクセスをセキュリティで保護する

ベスト プラクティスのガイダンス

クラスターをセキュリティで保護する最も重要な方法の 1 つは、Kubernetes API サーバーへのアクセスをセキュリティで保護することです。 API サーバーへのアクセスを制御するには、Kubernetes RBAC と Microsoft Entra ID を統合します。 これらのコントロールを使用して、Azure サブスクリプションへのアクセスをセキュリティで保護するのと同じ方法で AKS を保護します。

Kubernetes API サーバーには、クラスター内でアクションを実行する要求向けに単一の接続ポイントが用意されています。 API サーバーへのアクセスをセキュリティで保護および監査するには、アクセスを制限し、可能な最小限のレベルのアクセス許可を付与します。 このアプローチは Kubernetes に固有のものではありませんが、マルチテナントに使用するために AKS クラスターを論理的に分離している場合は特に重要です。

Microsoft Entra ID には、AKS クラスターと統合できるエンタープライズ対応の ID 管理ソリューションが用意されています。 Kubernetes には ID 管理ソリューションが用意されていないので、API サーバーへのアクセスを細かく制限することが困難な場合があります。 AKS の Microsoft Entra と統合されたクラスターでは、既存のユーザー アカウントとグループ アカウントを使用して API サーバーに対してユーザーを認証します。

AKS クラスターの Microsoft Entra 統合

Kubernetes RBAC と Microsoft Entra ID 統合を使用すると、API サーバーをセキュリティで保護し、1 つの名前空間と同様に、スコープが指定されたリソース セットに対して必要な最小限のアクセス許可を与えることができます。 異なる Microsoft Entra ユーザーまたはグループに異なる Kubernetes ロールを与えることができます。 きめ細かいアクセス許可を使用することで、API サーバーへのアクセスを制限し、実行されたアクションの明確な監査証跡を提供することができます。

AKS 自動では、承認とセキュリティベースラインは、サポートされている構成でより事前に構成されているため、オペレーターは検証、ガバナンス、例外処理に重点を置きます。 AKS Standard では、オペレーターは通常、これらのコントロールを直接構成し、ライフサイクル体制を維持します。

Microsoft Entra 統合、Kubernetes RBAC、および Azure RBAC の詳細については、「AKS での認証と承認のベスト プラクティス」を参照してください。

Instance Metadata API へのアクセスを制限する

ベスト プラクティスのガイダンス

すべてのユーザー名前空間にネットワーク ポリシーを追加して、メタデータ エンドポイントへのポッド エグレスをブロックします。

注

ネットワーク ポリシーを実装するには、AKS クラスターの作成時に属性 --network-policy azure を含めます。 次のコマンドを使用して、クラスターを作成します: az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

AKS Standard で、選択したネットワーク モデルとポリシー エンジンがこのポリシー パスをサポートしていることを確認します。 AKS Automatic で、クラスター構成でサポートされている同等の名前空間レベルのエグレス制限を適用します。

リソースへのコンテナー アクセスをセキュリティで保護する

ベスト プラクティスのガイダンス

コンテナーで実行できるアクションへのアクセスを制限します。 最小限のアクセス許可を付与し、ルート アクセスまたは特権エスカレーションの使用を避けます。

ユーザーまたはグループに必要最小限の特権を付与するのと同様に、コンテナーも必要なアクションとプロセスのみに制限するようにします。 攻撃のリスクを最小限に抑えるには、昇格された特権またはルート アクセスを必要とするアプリケーションとコンテナーを構成しないようにします。

ユーザー名前空間を使用すると、ホストの分離を向上させ、コンテナーのブレークアウトが発生した場合の横移動を制限できます。 これらの改善は、ポッドが root 権限で実行されているかどうかにかかわらず、重要です。

コンテナー アクションをさらにより細かく制御するには、"AppArmor" や "seccomp" など、組み込みの Linux セキュリティ機能を使用することもできます。

AKS Automatic によってセキュリティが強化された既定値が提供される場合でも、ワークロード レベルのセキュリティ制御はアプリケーションおよびプラットフォーム チームの責任のままです。

詳細については、「リソースへのコンテナー アクセスをセキュリティで保護する」を参照してください。

最新版の Kubernetes に定期的に更新する

ベスト プラクティスのガイダンス

新機能とバグ修正を常に最新の状態に保つには、AKS クラスターの Kubernetes バージョンを定期的にアップグレードしてください。

Kubernetes は、従来のインフラストラクチャ プラットフォームよりも速いペースで新機能をリリースしています。 Kubernetes の更新プログラムには以下が含まれます。

  • 新機能
  • バグまたはセキュリティの修正

新機能は通常、"アルファ版" と "ベータ版" のステータスを経て "安定版" になります。 安定版になると一般提供され、運用環境での使用が推奨されます。 Kubernetes の新機能のリリース サイクルを使用すると、定期的に重大な変更が発生したり、デプロイやテンプレートを調整したりすることなく、Kubernetes を更新できます。

AKS では、Kubernetes の 3 つのマイナー バージョンがサポートされています。 新しいマイナー パッチ バージョンが導入されると、サポートされている最も古いマイナー バージョンと修正プログラムのリリースは、提供終了となります。 Kubernetes のマイナー更新は定期的に行われます。 サポート対象であり続けるために、必要なアップグレードを確認するガバナンス プロセスを用意してください。 詳細については、「AKS でサポートされる Kubernetes のバージョン」を参照してください。

AKS 自動では、サポートされている構成ではアップグレード関連の動作がより事前に構成されており、オペレーターはワークロードの準備の検証とリリース ガバナンスに重点を置く必要があります。 AKS Standard では、オペレーターはアップグレード戦略とロールアウトのタイミングをより直接的に選択して管理します。

クラスターで使用できるバージョンを確認するには、次の例に示すように az aks get-upgrades コマンドを使用します。

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

その後、 az aks upgrade コマンドを使用して AKS クラスターをアップグレードできます。 アップグレード プロセスにより、次のことが安全に行われます。

  • ノードの遮断とドレインを一度に 1 つずつ行います。
  • 残りのノード上のポッドをスケジュールします。
  • 最新の OS および Kubernetes バージョンを実行している新しいノードをデプロイします。

重要

新しいマイナー バージョンを開発テスト環境でテストし、ワークロードが新しい Kubernetes バージョンでも正常であり続けることを検証します。

Kubernetes では、ワークロードが依存している API (バージョン 1.16 など) が非推奨になる可能性があります。 新しいバージョンを運用するとき、個々のバージョンで複数のノード プールを使用することを検証してください。そして、個々のプールを一度に 1 つずつアップグレードし、クラスター全体に更新を徐々に展開します。 複数のクラスターを実行している場合、一度に 1 つのクラスターをアップグレードし、影響や変更を段階的に監視します。

AKS のアップグレードの詳細については、「AKS でサポートされる Kubernetes のバージョン」と「AKS クラスターのアップグレード」を参照してください。

Linux ノード更新プログラムの処理

AKS の Linux ノードには、毎晩、ディストリビューション更新チャネルを介してセキュリティ修正プログラムが取得されます。 この動作は、ノードが AKS クラスターにデプロイされるときに自動的に構成されます。 中断や実行中のワークロードへの潜在的な影響を最小限に抑えるために、セキュリティ修正プログラムまたはカーネルの更新プログラムに必要な場合でも、ノードは自動的に再起動されません。 ノードの再起動を処理する方法については、「AKS のノードにセキュリティとカーネルの更新プログラムを適用する方法」を参照してください。

AKS の自動では、サポートされている構成ではノードの更新動作がより事前構成されています。 AKS Standard では、オペレーターは通常、明示的な運用制御を使用してパッチと再起動のガバナンスを定義します。

ノード イメージのアップグレード

無人アップグレードでは、Linux ノード OS にアップデートが適用されますが、クラスターのノードを作成するためのイメージは変更されません。 新しい Linux ノードがクラスターに追加された場合は、元のイメージを使用してノードが作成されます。 この新しいノードは、毎晩の自動チェックで利用可能なすべてのセキュリティおよびカーネル アップデートを受け取りますが、すべてのチェックと再起動が完了するまではパッチは適用されません。 ノード イメージのアップグレードを使用して、クラスターで使用されているノード イメージをチェックして更新することもできます。 ノード イメージのアップグレードに関する詳細については、「Azure Kubernetes Service (AKS) ノード イメージのアップグレード」を参照してください。

Windows Server ノード更新プログラムの処理

Windows Server ノードでは、ポッドを安全に切断およびドレインし、更新されたノードをデプロイするために、ノード イメージのアップグレード操作を定期的に実行します。

関連するコンテンツ

AKS と AKS クラスターのセキュリティ保護の詳細については、次の記事を参照してください。

  • Last updated on