GKE の seccomp について

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）の Linux の安全なコンピューティングモード（seccomp）について説明します。この情報を使用して、ノードをバックアップするホスト仮想マシン（VM）でコンテナ化されたアプリケーションが実行できるアクションを理解します。

seccomp とは

安全なコンピューティングモード（seccomp）は Linux のセキュリティ機能で、プロセスが Linux カーネルに対して行うシステムコール（syscall）を制限できます。

デフォルトでは、GKE ノードは containerd コンテナランタイムで Container-Optimized OS オペレーティングシステムを使用します。containerd は、許可される Linux 機能をデフォルトリストに制限して Linux カーネルを保護し、seccomp プロファイルを使用して、許可される syscall をさらに制限できます。containerd にはデフォルトの seccomp プロファイルがあります。GKE がデフォルトの seccomp プロファイルを適用するかどうかは、次のように、使用するクラスタモードによって異なります。

Autopilot（推奨）: GKE は、containerd のデフォルトの seccomp プロファイルをすべてのワークロードに自動的に適用します。
Standard: GKE では、すべてのワークロードに containerd のデフォルトの seccomp プロファイルを自動的には適用しません。ワークロードには、デフォルトの seccomp プロファイルまたはカスタム seccomp プロファイルを適用することをおすすめします。

デフォルトの containerd seccomp プロファイルは、ほとんどのワークロードとの互換性を維持しながら、ベースラインの強化を実現します。containerd の seccomp プロファイルの完全な定義は GitHub で入手できます。

Linux 機能と syscall

Linux システムで実行されている root 以外のプロセスで root ユーザーとして操作を行うには、特定の権限が必要になる場合があります。Linux では、capability を使用して利用可能な権限をグループに分割し、すべての権限を付与することなく、root 以外のプロセスが特定のアクションを実行できるようにします。特定の syscall を正常に行うプロセスには、capability によって付与される対応する権限が必要です。

Linux のすべての capability のリストについては、capability をご覧ください。

デフォルトの GKE seccomp プロファイルで拒否される syscall

containerd のデフォルトの seccomp プロファイルは、すべての syscall をブロックし、特定の syscall を選択的に許可します。一部の syscall は、ノードの VM の CPU アーキテクチャとカーネルバージョンによって異なります。DefaultProfile 関数の syscalls 変数は、すべてのアーキテクチャで許可されている syscall をリストします。

デフォルトの seccomp プロファイルは、コンテナ分離境界をバイパスしてノードまたは他のコンテナへの特権アクセスを許可するために使用できる syscall をブロックします。次の表に、デフォルトの seccomp プロファイルで拒否される重要な syscall をいくつか示します。

拒否される syscall
`mount`、`umount`、`umount2`、`fsmount`、`mount_setattr`	コンテナの境界外でノードファイルシステムへのアクセスや操作がされないようにプロセスを制限します。また、`CAP_SYS_ADMIN` capability はドロップされているため、拒否されます。
`bpf`	カーネル内で eBPF プログラムの作成がされないようにプロセスを制限します。eBPF プログラムは、ノードでの権限昇格につながる可能性があります。たとえば、CVE-2021-3490 は `bpf` syscall を使用しています。また、`CAP_SYS_ADMIN` capability はドロップされているため、拒否されます。
`clone`、`clone3`、`unshare`	コンテナの制限付き Namespace の外部にある可能性がある新しい Namespace に新しいプロセスの作成がされないように、プロセスを制限します。これらの新しいプロセスでは、権限や capability が昇格している場合があります。たとえば、CVE-2022-0185 は `unshare` syscall を使用しています。また、`CAP_SYS_ADMIN` capability はドロップされているため、拒否されます。
`reboot`	プロセスによるノードの再起動を制限します。また、`CAP_SYS_BOOT` capability はドロップされているため、拒否されます。
`open_by_handle_at`、`name_to_handle_at`	コンテナの外部にあるファイルへのアクセスを制限します。これらの syscall は、初期の Docker コンテナエスケープの脆弱性の悪用で使用されたものです。また、`CAP_DAC_READ_SEARCH` capability と `CAP_SYS_ADMIN` capability はドロップされているため、拒否されます。

GKE で seccomp を使用する方法

Autopilot クラスタでは、GKE は containerd のデフォルトの seccomp プロファイルをすべてのワークロードに自動的に適用します。以後の対応は特に必要ありません。制限付き syscall を実行しようとすると、失敗します。GKE がノードを管理するため、Autopilot はカスタム seccomp プロファイルを禁止します。

Standard クラスタでは、seccomp プロファイルを手動で適用する必要があります。GKE はユーザーに対してプロファイルを適用しません。

Standard クラスタで seccomp を有効にする

次の例に示すように、Pod 仕様の spec.securityContext.seccompProfile フィールドを使用して Pod またはコンテナのセキュリティコンテキストを設定し、seccomp プロファイルを手動で適用します。ユースケースで制限付き syscall を使用する必要がない限り、ワークロードには seccomp プロファイルを使用することを強くおすすめします。サポートされている 2 つの seccompProfile のタイプは次のとおりです。

RuntimeDefault: containerd ランタイムで指定されたデフォルトのプロファイル。
Localhost: カスタムプロファイルの定義。

次のマニフェストの例では、seccomp プロファイルをランタイムのデフォルトプロファイルに設定します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: default-pod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: default-pod
  template:
    metadata:
      labels:
        app: default-pod
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: seccomp-test
        image: nginx

このマニフェストをデプロイする場合、Pod 内のコンテナがランタイムのデフォルト seccomp プロファイルに違反する syscall を作成しようとすると、Pod またはワークロードで予期しない動作が発生することがあります。たとえば、起動時に制限付き syscall を行う Pod は起動に失敗します。Pod の実行中にアプリケーションが制限付き syscall を実行しようとすると、コンテナにエラーが表示されることがあります。失敗した syscall の重大度は、アプリケーションによるエラーの処理方法によって異なります。

Standard クラスタでカスタム seccomp プロファイルを使用する

ランタイムのデフォルト seccomp プロファイルが、アプリケーションに対して制限が厳しすぎる（または制限が十分でない）場合は、Standard クラスタの seccomp プロファイルを Pod に適用できます。このプロセスでは、ノード上のファイルシステムにアクセスする必要があります。カスタム seccomp プロファイルを読み込んで使用する方法については、seccomp を使用してコンテナの syscall を制限するをご覧ください。