第12章 seccomp プロファイルの設定

OpenShift Container Platform コンテナーまたは Pod は、1 つ以上の明確に定義されたタスクを実行するアプリケーションを 1 つ実行します。アプリケーションには通常、基礎となるオペレーティングシステムカーネル API の小規模なサブセットのみが必要です。セキュアコンピューティングモードである seccomp は Linux カーネル機能で、これを使用して、コンテナーで実行されているプロセスを制限して、利用可能なシステム呼び出しのサブセットだけが使用できるようにできます。

restricted-v2 SCC は、4.12 で新しく作成されたすべての Pod に適用されます。これらの Pod には、デフォルトの seccomp プロファイル runtime/default が適用されます。

seccomp プロファイルは、ディスクに JSON ファイルとして保存されます。

重要

seccomp プロファイルは特権付きコンテナーに適用できません。

12.1. Pod に適用されるデフォルトの seccomp プロファイルの確認

OpenShift Container Platform には、デフォルトの seccomp プロファイルが同梱されており、runtime/default として参照されます。4.12 では、新しく作成された Pod の Security Context Constraint (SCC) が restricted-v2 に設定され、デフォルトの seccomp プロファイルが Pod に適用されます。

手順

  1. 次のコマンドを実行して、Pod に設定されている Security Context Constraint (SCC) とデフォルトの seccomp プロファイルを確認できます。

    1. namespace で実行されている Pod を確認します。

      $ oc get pods -n <namespace>

      たとえば、workshop namespace で実行されている Pod を確認するには、次を実行します。

      $ oc get pods -n workshop

      出力例

      NAME                READY   STATUS      RESTARTS   AGE
      parksmap-1-4xkwf    1/1     Running     0          2m17s
      parksmap-1-deploy   0/1     Completed   0          2m22s

    2. Pod を調べます。

      $ oc get pod parksmap-1-4xkwf -n workshop -o yaml

      出力例

      apiVersion: v1
      kind: Pod
      metadata:
        annotations:
          k8s.v1.cni.cncf.io/network-status: |-
            [{
                "name": "openshift-sdn",
                "interface": "eth0",
                "ips": [
                    "10.131.0.18"
                ],
                "default": true,
                "dns": {}
            }]
          k8s.v1.cni.cncf.io/networks-status: |-
            [{
                "name": "openshift-sdn",
                "interface": "eth0",
                "ips": [
                    "10.131.0.18"
                ],
                "default": true,
                "dns": {}
            }]
          openshift.io/deployment-config.latest-version: "1"
          openshift.io/deployment-config.name: parksmap
          openshift.io/deployment.name: parksmap-1
          openshift.io/generated-by: OpenShiftWebConsole
          openshift.io/scc: restricted-v2 1
          seccomp.security.alpha.kubernetes.io/pod: runtime/default 2

      1
      ワークロードが別の SCC にアクセスできない場合、restricted-v2 SCC がデフォルトで追加されます。
      2
      4.12 で新しく作成された Pod には、SCC によって義務付けられているように、runtime/default に設定された seccomp プロファイルがあります。

12.1.1. アップグレードされたクラスター

4.12 にアップグレードされたクラスターでは、すべての認証済みユーザーが restricted および restricted-v2 SCC にアクセスできます。

たとえば、アップグレード時に OpenShift Container Platform v4.10 クラスターで restricted となった SCC によって許可されたワークロードは、restricted-v2 によって許可される場合があります。これは、restricted-v2restrictedrestricted-v2 の間のより制限的な SCC であるためです。

注記

ワークロードは retricted-v2 で実行できる必要があります。

逆に、privilegesEscalation: true を必要とするワークロードでは、このワークロードは、認証されたユーザーが使用できる restricted SCC を引き続き持ちます。これは、restricted-v2privilegesEscalation を許可しないためです。

12.1.2. 新しくインストールされたクラスター

新しくインストールされた OpenShift Container Platform v4.11 以降のクラスターの場合、restricted-v2 は、認証されたユーザーが使用できる SCC として restricted SCC を置き換えます。デフォルトで認証されたユーザーが使用できる SCC は restricted-v2 のみであるため、privilegeEscalation: true を持つワークロードはクラスターへの参加が許可されません。

機能の privilegeEscalation は、restricted では許可されていますが、restricted-v2 では許可されていません。restricted SCC で許可されていたよりも多くの機能が、restricted-v2 によって拒否されます。

新しくインストールされた OpenShift Container Platform v4.11 以降のクラスターには、privilegeEscalation: true を持つワークロードが許可される場合があります。RoleBinding を使用して、ワークロードを実行している ServiceAccount (またはこのワークロードを許可できるその他の SCC) に restricted SCC へのアクセスを許可するには、次のコマンドを実行します。

$ oc -n <workload-namespace> adm policy add-scc-to-user <scc-name> -z <serviceaccount_name>

OpenShift Container Platform 4.12 では、pod アノテーション seccomp.security.alpha.kubernetes.io/pod: runtime/default および container.seccomp.security.alpha.kubernetes.io/<container_name>: runtime/default を追加する機能は非推奨です。