第13章 seccomp プロファイルの設定
OpenShift Container Platform コンテナーまたは Pod は、1 つ以上の明確に定義されたタスクを実行するアプリケーションを 1 つ実行します。アプリケーションには通常、基礎となるオペレーティングシステムカーネル API の小規模なサブセットのみが必要です。セキュアコンピューティングモードである seccomp は Linux カーネル機能で、これを使用して、コンテナーで実行されているプロセスを制限して、利用可能なシステム呼び出しのサブセットだけが使用できるようにできます。
restricted-v2
SCC は、4.14 で新しく作成されたすべての Pod に適用されます。これらの Pod には、デフォルトの seccomp プロファイル runtime/default
が適用されます。
seccomp プロファイルは、ディスクに JSON ファイルとして保存されます。
seccomp プロファイルは特権付きコンテナーに適用できません。
13.1. Pod に適用されるデフォルトの seccomp プロファイルの確認
OpenShift Container Platform には、デフォルトの seccomp プロファイルが同梱されており、runtime/default
として参照されます。4.14 では、新しく作成された Pod の Security Context Constraint (SCC) が restricted-v2
に設定され、デフォルトの seccomp プロファイルが Pod に適用されます。
手順
次のコマンドを実行して、Pod に設定されている Security Context Constraint (SCC) とデフォルトの seccomp プロファイルを確認できます。
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
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/network-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
13.1.1. アップグレードされたクラスター
4.14 にアップグレードされたクラスターでは、すべての認証済みユーザーが restricted
および restricted-v2
SCC にアクセスできます。
たとえば、アップグレード時に OpenShift Container Platform v4.10 クラスターで restricted
となった SCC によって許可されたワークロードは、restricted-v2
によって許可される場合があります。これは、restricted-v2
が restricted
と restricted-v2
の間のより制限的な SCC であるためです。
ワークロードは retricted-v2
で実行できる必要があります。
逆に、privilegeEscalation: true
を必要とするワークロードでは、このワークロードは、認証されたユーザーが使用できる restricted
SCC を引き続き持ちます。これは、restricted-v2
が privilegeEscalation
を許可しないためです。
13.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.14 では、Pod アノテーション seccomp.security.alpha.kubernetes.io/pod: runtime/default
および container.seccomp.security.alpha.kubernetes.io/<container_name>: runtime/default
を追加する機能は非推奨となりました。