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

[アーティクル]
08/04/2024

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

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

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

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

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

たとえば、ポッドのマニフェストには allowPrivilegeEscalation: false を設定します。このような Kubernetes 組み込みの "ポッドのセキュリティコンテキスト" を使用して、実行するユーザーやグループ、公開する Linux 機能など、追加のアクセス許可を定義できます。その他のベストプラクティスについては、リソースへのポッドのアクセスをセキュリティで保護する方法に関する記事を参照してください。

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

ノードレベルで Linux セキュリティ機能を定義します。
ポッドマニフェストを使用して機能を実装します。

組み込みの Linux セキュリティ機能は、Linux ノードとポッドに対してのみ使用できます。

Note

現在、Kubernetes 環境は悪意のあるマルチテナントの使用に対して完全に安全ではありません。 Microsoft Defender for Containers AppArmor、seccomp、Pod Security Admission、ノードの Kubernetes RBAC などの追加のセキュリティ機能は、悪用を効果的にブロックします。

悪意のあるマルチテナントワークロードを実行する場合の真のセキュリティを実現するために、ハイパーバイザーのみを信頼してください。 Kubernetes 用のセキュリティドメインは、個々のノードではなく、クラスター全体になります。

この種の悪意のあるマルチテナントワークロードでは、物理的に分離されたクラスターを使用する必要があります。

App Armor

コンテナーアクションを制限するために、AppArmor Linux カーネルセキュリティモジュールを使用できます。 AppArmor は基となる AKS ノード OS に含まれており、既定で有効です。読み取り、書き込み、実行のアクション、またはファイルシステムのマウントなどのシステム機能を制限する AppArmor プロファイルを作成します。既定の AppArmor プロファイルでは、さまざまな /proc と /sys の場所へのアクセスが制限されており、基となるノードからコンテナーを論理的に分離する手段が用意されています。 AppArmor は、Kubernetes ポッドだけでなく、Linux 上で動作するあらゆるアプリケーションに対応しています。

コンテナーの動作を制限するために AKS クラスターで使用されている AppArmor プロファイル

AppArmor の動作を確認するために、次の例ではファイルへの書き込みを防止するプロファイルを作成します。

AKS ノードに SSH を接続します。
deny-write.profile という名前のファイルを作成します。

次のコンテンツをコピーして貼り付けます。

#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,
  # Deny all file writes.
  deny /** w,
}

apparmor_parser コマンドを使用して AppArmor プロファイルが追加されます。

プロファイルを AppArmor に追加します。
前の手順で作成したプロファイルの名前を指定します。
```
sudo apparmor_parser deny-write.profile
```
プロファイルが正しく解析され、AppArmor に適用された場合、出力は表示されず、コマンドプロンプトに戻ります。

ローカルコンピューターから、aks-apparmor.yaml という名前のポッドマニフェストを作成します。このマニフェストにより:

container.apparmor.security.beta.kubernetes の注釈を定義します。
前の手順で作成した deny-write プロファイルを参照します。

apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
  - name: hello
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

ポッドがデプロイされたら、次のコマンドを実行して、hello-apparmor ポッドに Running 状態が表示されていることを確認します。

kubectl get pods

NAME             READY   STATUS    RESTARTS   AGE
aks-ssh          1/1     Running   0          4m2s
hello-apparmor   0/1     Running   0          50s

AppArmor の詳細については、Kubernetes の AppArmor プロファイルに関する記事を参照してください。

セキュアコンピューティング

AppArmor は任意の Linux アプリケーションで機能しますが、seccomp (secure computing) はプロセスレベルで機能します。 seccomp は Linux カーネルセキュリティモジュールでもあり、AKS ノードで使用される Docker ランタイムでネイティブにサポートされています。 seccomp を使用してコンテナーのプロセス呼び出しを制限できます。次の方法で、実行する最小限のアクセス許可のみをコンテナーに付与するというベストプラクティスに従います。

フィルターを使用して、どのアクションを許可または拒否するかを定義する。
ポッドの YAML マニフェスト内に、seccomp フィルターに関連付けるための注釈を付ける。

seccomp の動作を確認するには、ファイルに対するアクセス許可の変更を防止するフィルターを作成します。

AKS ノードに SSH を接続します。
/var/lib/kubelet/seccomp/prevent-chmod という名前の seccomp フィルターを作成します。

次のコンテンツをコピーして貼り付けます。

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "name": "chmod",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "fchmodat",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "chmodat",
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

バージョン 1.19 以降では、以下を構成する必要があります。

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["chmod","fchmodat","chmodat"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

ローカルコンピューターから、aks-seccomp.yaml という名前のポッドマニフェストを作成し、次の内容を貼り付けます。このマニフェストにより:

seccomp.security.alpha.kubernetes.io の注釈を定義します。
前の手順で作成した prevent-chmod フィルターを参照します。

apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
spec:
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

バージョン 1.19 以降では、以下を構成する必要があります。

apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: prevent-chmod
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

kubectl apply コマンドを使用してサンプルポッドを展開します。
```
kubectl apply -f ./aks-seccomp.yaml
```
kubectl get pods コマンドを使用して、ポッドの状態を確認します。
- ポッドからはエラーが報告されています。
- 次の出力例に示すように、chmod コマンドは seccomp フィルターによって実行されません。
```
kubectl get pods

NAME                      READY     STATUS    RESTARTS   AGE
chmod-prevented           0/1       Error     0          7s
```

使用できるフィルターの詳細については、「Seccomp security profiles for Docker (Docker の Seccomp セキュリティプロファイル)」を参照してください。

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

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

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

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

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

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

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

Azure CLI
Azure PowerShell

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

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

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

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

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

Get-AzAksUpgradeProfile -ResourceGroupName myResourceGroup -ClusterName myAKSCluster |
Select-Object -Property Name, ControlPlaneProfileKubernetesVersion -ExpandProperty ControlPlaneProfileUpgrade |
Format-Table -Property *

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

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

重要

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

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

Azure CLI
Azure PowerShell

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

Set-AzAksCluster -ResourceGroupName myResourceGroup -Name myAKSCluster -KubernetesVersion <KUBERNETES_VERSION>

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

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

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

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

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

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

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

次の方法で共有

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

脅威保護を有効にする

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

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

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

App Armor

セキュアコンピューティング

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

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

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

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

その他のリソース

次の方法で共有

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

脅威保護を有効にする

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

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

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

App Armor

セキュア コンピューティング

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

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

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

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

その他のリソース

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

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

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

セキュアコンピューティング

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