次の方法で共有

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

  • [アーティクル]

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

この記事では、AKS クラスターをセキュリティで保護する方法について説明します。 以下の方法について説明します。

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

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

脅威保護を有効にする

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

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

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 サーバーへのアクセスを制限し、実行されたアクションの明確な監査証跡を提供することができます。

推奨されるベスト プラクティスとして、個々の ID ではなく、"グループ" を使用してファイルとフォルダーへのアクセス権を付与します。 たとえば、Microsoft Entra ID グループ メンバーシップを使用して、ユーザーを個々の ユーザー ではなく Kubernetes ロールにバインドします。 ユーザーのグループ メンバーシップが変わると、それに応じて AKS クラスターに対するアクセス許可も変わります。

ここでは、個々のユーザーをロールに直接バインドし、彼らの職務は変わるとします。 Microsoft Entra グループのメンバーシップには更新が行われますが、AKS クラスターに対するアクセス許可には行われません。 このシナリオでは、最終的に、ユーザーに必要なアクセス許可よりも多くのアクセス許可が付与されることになります。

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

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

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

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

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

コンテナー アクションをさらにより細かく制御するには、AppArmor や seccomp など、組み込みの Linux セキュリティ機能を使用することもできます。 詳細については、「リソースへのコンテナー アクセスをセキュリティで保護する」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

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

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

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

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

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

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

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