組み込みの Linux セキュリティ機能を使用したリソースへのセキュリティ コンテナー アクセス

この記事では、Azure Kubernetes Service (AKS) ワークロードのリソースへのコンテナー アクセスをセキュリティで保護する方法について説明します。

概要

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

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

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

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

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

App Armor

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

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

1. AKS ノードに SSH を接続します。

2. deny-write.profile という名前のファイルを作成します。

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

   #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 プロファイルが追加されます。

1. プロファイルを AppArmor に追加します。

2. 前の手順で作成したプロファイルの名前を指定します。

   sudo apparmor_parser deny-write.profile
   

   プロファイルが正しく解析され、AppArmor に適用された場合、出力は表示されず、コマンド プロンプトに戻ります。

3. ローカル コンピューターから、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" ]
   

4. ポッドがデプロイされたら、次のコマンドを実行して、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 プロファイルに関する記事を参照してください。

セキュア コンピューティング (seccomp)

AppArmor は任意の Linux アプリケーションで機能しますが、seccomp (secure computing) はプロセス レベルで機能します。 seccomp は Linux カーネルのセキュリティ モジュールでもあり、AKS ノードで使用される containerd ランタイムでネイティブにサポートされています。 seccomp を使用してコンテナーのシステム コールを制限できます。 seccomp は、悪意のあるアクターが悪用する一般的なシステム コールの脆弱性に対して追加の保護レイヤーを確立し、ノード内のすべてのワークロードに既定のプロファイルを指定できるようにします。

既定の seccomp プロファイルを構成する (プレビュー)

新しい Linux ノード プールを作成する際に、カスタム ノード構成を使用して、既定の seccomp プロファイルを適用できます。 AKS では、 RuntimeDefault と Unconfinedの 2 つの値がサポートされています。 ワークロードによっては、他のワークロードよりも低い数の syscall 制限が必要となる場合があります。 つまり、'RuntimeDefault' プロファイルを使用すると実行時に失敗する可能性が生じます。 Unconfined プロファイルを指定すると、このような失敗を軽減することができます。 ワークロードでカスタム プロファイルが必要な場合は、「カスタム seccomp プロファイルを構成する」を参照してください。

制限事項

• SeccompDefault は、Windows ノード プールでサポートされているパラメーターではありません。
• SeccompDefault は、2024-09-02-preview API 以降で使用できます。

KubeletDefaultSeccompProfilePreview 機能フラグを登録する

1. az feature register コマンドを使用して、KubeletDefaultSeccompProfilePreview 機能フラグを登録します。

   az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

   状態が [登録済み] と表示されるまでに数分かかります。

2. az feature show コマンドを使用して、登録の状態を確認します。

   az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

3. 状態が Registered と表示されたら、az provider register コマンドを使用して Microsoft.ContainerService リソース プロバイダーの登録を最新の情報に更新します。

   az provider register --namespace Microsoft.ContainerService
   

seccomp を使用してコンテナーのシステム コールを制限する

1."seccompDefault": "RuntimeDefault" を指定して、kubelet 構成に seccomp プロファイルを適用する手順に従います。

RuntimeDefault は containerd の既定の seccomp プロファイルを使用し、特定のシステム呼び出しを制限してセキュリティを強化します。 制限付きの syscall は失敗します。 詳細については、「containerD の既定の seccomp プロファイル」を参照してください。

2.構成が適用されたことを確認します。

ホストに接続し、構成の変更がファイル システムで行われていることを確認すれば、ノードに設定が適用されたことを確認できます。

3.ワークロード エラーのトラブルシューティング。

SeccompDefault が有効になっている場合、コンテナー ランタイムの既定の seccomp プロファイルが、ノードでスケジュールされているすべてのワークロードに既定で使用されます。 その結果、ブロックされた syscall が原因でワークロードにエラーが発生する可能性があります。 ワークロード エラーが発生した場合は、次のようなエラーが表示されることがあります。

• 機能が有効になった後に想定外のワークロードが存在すると、「アクセス許可が拒否されました」というエラーが表示されます。
• seccomp のエラー メッセージは、既定のプロファイルで SCMP_ACT_ERRNO を SCMP_ACT_LOG に置き換えれば、auditd または syslog でも表示できます。

上記のエラーが発生した場合は、seccomp プロファイルを Unconfinedに変更することをお勧めします。 Unconfined では syscall に制限はなく、すべてのシステム コールが許可され、セキュリティが低下します。

カスタム seccomp プロファイルを構成する

カスタム seccomp プロファイルを使用すると、制限付き syscall をより細かく制御できます。 次の方法で、実行する最小限のアクセス許可のみをコンテナーに付与するというベスト プラクティスに従います。

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

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

1. AKS ノードに SSH を接続します。

2. /var/lib/kubelet/seccomp/prevent-chmod という名前の seccomp フィルターを作成します。

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

   {
     "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"
       }
     ]
   }
   

4. ローカル コンピューターから、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
   

5. kubectl apply コマンドを使用してサンプル ポッドを展開します。

   kubectl apply -f ./aks-seccomp.yaml
   

6. kubectl get pods コマンドを使用して、ポッドの状態を確認します。

   • ポッドからはエラーが報告されています。
   • 出力例に示すように、chmod コマンドは seccomp フィルターでは実行されません。

   kubectl get pods
   
   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s
   

seccomp セキュリティ プロファイル のオプション

seccomp セキュリティ プロファイルは、許可また制限された定義済みの syscall がまとめられたものです。 ほとんどのコンテナー ランタイムには既定の seccomp プロファイルがあり、Docker で使用されているものと同じではありませんが類似しています。 使用可能なプロファイルの詳細については、「Docker または containerD の既定の seccomp プロファイル」を参照してください。

AKS では、カスタム ノード構成を使用して seccomp を構成する場合、RuntimeDefault 用に containerD の既定の seccomp プロファイルを使用します。

既定のプロファイルでブロックされた重要な syscall

Docker と containerD の両方で、安全な syscall の許可リストを管理します。 次の表に、許可リストになく、効果的にブロックされる重要な syscall の一部を示します。 ブロックされた syscall のいずれかがワークロードで必要な場合は、RuntimeDefault seccomp プロファイルを使用しないでください。

Docker と containerD に変更が加えられた場合、AKS は既定の構成と一致するように更新します。 このリストを更新すると、ワークロード エラーが発生する可能性があります。 リリースの最新情報については、「AKS リリース ノート」を参照してください。

次のステップ

関連付けられているベスト プラクティスについては、AKS でのクラスターのセキュリティとアップグレードに関するベスト プラクティスのページと、AKS でのポッドのセキュリティに関するベスト プラクティスのページを参照してください。