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

FEATURE STATE: Kubernetes v1.19 [stable]

seccomp(SECure COMPuting mode)はLinuxカーネル2.6.12以降の機能です。この機能を用いると、ユーザー空間からカーネルに対して発行できるシステムコールを制限することで、プロセス権限のサンドボックスを構築することができます。 Kubernetesでは、ノード上で読み込んだseccompプロファイルをPodやコンテナに対して自動で適用することができます。

あなたのワークロードが必要とする権限を特定するのは、実際には難しい作業になるかもしれません。このチュートリアルでは、ローカルのKubernetesクラスターでseccompプロファイルを読み込むための方法を説明し、seccompプロファイルのPodへの適用方法について学んだ上で、コンテナプロセスに対して必要な権限のみを付与するためのseccompプロファイルを作成する方法を概観していきます。

目標

ノードでseccompプロファイルを読み込む方法を学ぶ。
seccompプロファイルをコンテナに適用する方法を学ぶ。
コンテナプロセスが生成するシステムコールの監査出力を確認する。
seccompプロファイルが指定されない場合の挙動を確認する。
seccompプロファイルの違反を確認する。
きめ細やかなseccompプロファイルの作成方法を学ぶ。
コンテナランタイムの標準seccompプロファイルを適用する方法を学ぶ。

始める前に

このチュートリアルのステップを完了するためには、kindとkubectlをインストールしておく必要があります。

このチュートリアルで利用するコマンドは、Dockerをコンテナランタイムとして利用していることを前提としています。 (kindが作成するクラスターは内部的に異なるコンテナランタイムを利用する可能性があります)。 Podmanを使うこともできますが、チュートリアルを完了するためには、所定の手順に従う必要があります。

このチュートリアルでは、現時点(v1.25以降)でのベータ機能を利用する設定例をいくつか示しますが、その他の例についてはGAなseccomp関連機能を用いています。利用するKubernetesバージョンを対象としたクラスターの正しい設定がなされていることを確認してください。

チュートリアル内では、サンプルをダウンロードするためにcurlを利用します。この手順については、ほかの好きなツールを用いて実施してもかまいません。

備考:

securityContextにprivileged: trueが設定されているContainerに対しては、seccompプロファイルを適用することができません。特権コンテナは常にUnconfinedな状態で動作します。

サンプルのseccompプロファイルをダウンロードする

プロファイルの内容については後で解説しますので、まずはクラスターで読み込むためのseccompプロファイルをprofiles/ディレクトリ内にダウンロードしましょう。

class=copy-code-icon>pods/security/seccomp/profiles/audit.json index.php?q=aHR0cHM6Ly9rdWJlcm5ldGVzLmlvL2ltYWdlcy9jb3B5Y29kZS5zdmc%3D" class="icon-copycode" title="Copy pods/security/seccomp/profiles/audit.json to clipboard">

{ "defaultAction": "SCMP_ACT_LOG" }

pods/security/seccomp/profiles/violation.json index.php?q=aHR0cHM6Ly9rdWJlcm5ldGVzLmlvL2ltYWdlcy9jb3B5Y29kZS5zdmc%3D" class="icon-copycode" title="Copy pods/security/seccomp/profiles/violation.json to clipboard">

{ "defaultAction": "SCMP_ACT_ERRNO" }

pods/security/seccomp/profiles/fine-grained.json index.php?q=aHR0cHM6Ly9rdWJlcm5ldGVzLmlvL2ltYWdlcy9jb3B5Y29kZS5zdmc%3D" class="icon-copycode" title="Copy pods/security/seccomp/profiles/fine-grained.json to clipboard">

{ "defaultAction": "SCMP_ACT_ERRNO", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "accept4", "epoll_wait", "pselect6", "futex", "madvise", "epoll_ctl", "getsockname", "setsockopt", "vfork", "mmap", "read", "write", "close", "arch_prctl", "sched_getaffinity", "munmap", "brk", "rt_sigaction", "rt_sigprocmask", "sigaltstack", "gettid", "clone", "bind", "socket", "openat", "readlinkat", "exit_group", "epoll_create1", "listen", "rt_sigreturn", "sched_yield", "clock_gettime", "connect", "dup2", "epoll_pwait", "execve", "exit", "fcntl", "getpid", "getuid", "ioctl", "mprotect", "nanosleep", "open", "poll", "recvfrom", "sendto", "set_tid_address", "setitimer", "writev", "fstatfs", "getdents64", "pipe2", "getrlimit" ], "action": "SCMP_ACT_ALLOW" } ] }

次のコマンドを実行してください:

mkdir ./profiles
curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json
curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json
curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json
ls profiles

最終的に3つのプロファイルが確認できるはずです:

audit.json  fine-grained.json  violation.json

kindでローカルKubernetesクラスターを構築する

手軽な方法として、kindを利用することで、seccompプロファイルを読み込んだ単一ノードクラスターを構築できます。 kindはKubernetesをDocker内で稼働させるため、クラスターの各ノードはコンテナとなります。これにより、ノード上にファイルを展開するのと同じように、各コンテナのファイルシステムに対してファイルをマウントすることが可能です。

pods/security/seccomp/kind.yaml

apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
- role: control-plane
  extraMounts:
  - hostPath: "./profiles"
    containerPath: "/var/lib/kubelet/seccomp/profiles"

kindの設定サンプルをダウンロードして、kind.yamlの名前で保存してください:

curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml

ノードのコンテナイメージを設定する際には、特定のKubernetesバージョンを指定することもできます。この設定方法の詳細については、kindのドキュメント内の、ノードの項目を参照してください。このチュートリアルではKubernetes v1.34を使用することを前提とします。

ベータ機能として、Unconfinedにフォールバックするのではなく、コンテナランタイムがデフォルトで推奨するプロファイルを利用するようにKubernetesを設定することもできます。この機能を試したい場合、これ以降の手順に進む前に、全ワークロードに対する標準seccompプロファイルとしてRuntimeDefaultを使用するを参照してください。

kindの設定ファイルを設置したら、kindクラスターを作成します:

kind create cluster --config=kind.yaml

Kubernetesクラスターが準備できたら、単一ノードクラスターが稼働しているDockerコンテナを特定してください:

docker ps

kind-control-planeという名前のコンテナが稼働していることが確認できるはずです。出力は次のようになるでしょう:

CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                       NAMES
6a96207fed4b        kindest/node:v1.18.2   "/usr/local/bin/entr…"   27 seconds ago      Up 24 seconds       127.0.0.1:42223->6443/tcp   kind-control-plane

このコンテナのファイルシステムを観察すると、profiles/ディレクトリがkubeletのデフォルトのseccompパスとして正しく読み込まれていることを確認できるはずです。 Pod内でコマンドを実行するためにdocker execを使います:

# 6a96207fed4bを"docker ps"で確認したコンテナIDに変更してください。
docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles

audit.json  fine-grained.json  violation.json

kind内で稼働しているkubeletがseccompプロファイルを利用可能であることを確認しました。

コンテナランタイムの標準seccompプロファイルを利用してPodを作成する

ほとんどのコンテナランタイムは、許可・拒否の対象とする標準的なシステムコールの集合を提供しています。

PodやContainerのセキュリティコンテキストでseccompタイプをRuntimeDefaultに設定すると、コンテナランタイムが提供するデフォルトのプロファイルをワークロードに適用することができます。

備考:

seccompDefaultの設定を有効化している場合、他にseccompプロファイルを定義しなくても、PodはRuntimeDefault seccompプロファイルを使用します。 seccompDefaultが無効の場合のデフォルトはUnconfinedです。

Pod内の全てのContainerに対してRuntimeDefault seccompプロファイルを要求するマニフェストは次のようなものです:

pods/security/seccomp/ga/default-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: default-pod
  labels:
    app: default-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some more syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

このPodを作成してみます:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml

kubectl get pod default-pod

Podが正常に起動できていることを確認できるはずです:

NAME        READY   STATUS    RESTARTS   AGE
default-pod 1/1     Running   0          20s

次のセクションに進む前に、Podを削除します:

kubectl delete pod default-pod --wait --now

システムコール監査のためのseccompプロファイルを利用してPodを作成する

最初に、新しいPodにプロセスの全システムコールを記録するためのaudit.jsonプロファイルを適用します。

このPodのためのマニフェストは次の通りです:

pods/security/seccomp/ga/audit-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: audit-pod
  labels:
    app: audit-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/audit.json
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

備考:

過去のバージョンのKubernetesでは、を用いてseccompの挙動を制御することができました。 Kubernetes 1.34におけるseccompの設定では.spec.securityContextフィールドのみをサポートしており、このチュートリアルではKubernetes 1.34における手順を解説しています。

クラスター内にPodを作成します:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/audit-pod.yaml

このプロファイルは、いかなるシステムコールも制限しないため、Podは正常に起動するはずです。

kubectl get pod audit-pod

NAME        READY   STATUS    RESTARTS   AGE
audit-pod   1/1     Running   0          30s

このコンテナが公開するエンドポイントとやりとりするために、kindのコントロールプレーンコンテナの内部からこのエンドポイントにアクセスできるように、NodePort Serviceを作成します。

kubectl expose pod audit-pod --type NodePort --port 5678

どのポートがノード上のServiceに割り当てられたのかを確認しましょう。

kubectl get service audit-pod

次のような出力が得られます:

NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
audit-pod   NodePort   10.111.36.142   <none>        5678:32373/TCP   72s

ここまで来れば、kindのコントロールプレーンコンテナの内部からエンドポイントに対して、Serviceが公開するポートを通じてcurlで接続することができます。 docker execを使って、コントロールプレーンコンテナに属するコンテナの中からcurlを実行しましょう:

# 6a96207fed4bと32373を、それぞれ"docker ps"で確認したコンテナIDとポート番号に変更してください。
docker exec -it 6a96207fed4b curl localhost:32373

just made some syscalls!

プロセスが実行されていることは確認できましたが、実際にどんなシステムコールが発行されているのでしょうか？このPodはローカルクラスターで稼働しているため、発行されたシステムコールを/var/log/syslogで確認することができるはずです。新しいターミナルを開いて、http-echoが発行するシステムコールをtailしてみましょう:

# あなたのマシンのログは"/var/log/syslog"以外の場所にあるかもしれません。
tail -f /var/log/syslog | grep 'http-echo'

すでにhttp-echoが発行したいくつかのシステムコールのログが見えているはずです。コントロールプレーンコンテナ内から再度curlを実行すると、新たにログに追記された内容が出力されます。

例えば、次のような出力が得られるでしょう:

Jul  6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000
Jul  6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul  6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul  6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000

各行のsyscall=エントリに着目することで、http-echoプロセスが必要とするシステムコールを理解していくことができるでしょう。このプロセスが利用する全てのシステムコールを網羅するものではないかもしれませんが、このコンテナのseccompプロファイルを作成する上での基礎とすることは可能です。

次のセクションに進む前にServiceとPodを削除します:

kubectl delete service audit-pod --wait
kubectl delete pod audit-pod --wait --now

違反が発生するseccompプロファイルでPodを作成する

デモとして、いかなるシステムコールも許可しないseccompプロファイルをPodに適用してみましょう。

マニフェストは次の通りです:

pods/security/seccomp/ga/violation-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: violation-pod
  labels:
    app: violation-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/violation.json
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

クラスターにPodを作成してみます:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/violation-pod.yaml

Podを作成しても問題が発生します。 Podの状態を確認すると、起動に失敗していることが確認できるはずです。

kubectl get pod violation-pod

NAME            READY   STATUS             RESTARTS   AGE
violation-pod   0/1     CrashLoopBackOff   1          6s

直前の事例で見てきたように、http-echoプロセスは多くのシステムコールを必要とします。ここでは"defaultAction": "SCMP_ACT_ERRNO"が設定されているため、あらゆるシステムコールに対してseccompがエラーを発生させました。

この構成はとてもセキュアですが、有意義な処理は何もできないことを意味します。私たちが実際にやりたいのは、ワークロードが必要とする権限のみを付与することです。

次のセクションに進む前にPodを削除します。

kubectl delete pod violation-pod --wait --now

必要なシステムコールのみを許可するseccompプロファイルを用いてPodを作成する

fine-grained.jsonプロファイルの内容を見れば、最初の例で"defaultAction":"SCMP_ACT_LOG"を設定していた際に、ログに表示されたシステムコールが含まれていることに気づくでしょう。今回のプロファイルでも"defaultAction": "SCMP_ACT_ERRNO"を設定しているものの、"action": "SCMP_ACT_ALLOW"ブロックで明示的に一連のシステムコールを許可しています。理想的な状況下であれば、コンテナが正常に稼働することに加え、syslogへのメッセージ送信を見ることはなくなるでしょう。

この事例のマニフェストは次の通りです:

pods/security/seccomp/ga/fine-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: fine-pod
  labels:
    app: fine-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/fine-grained.json
  containers:
  - name: test-container
    image: hashicorp/http-echo:1.0
    args:
    - "-text=just made some syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

クラスター内にPodを作成します:

kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/fine-pod.yaml

kubectl get pod fine-pod

Podは正常に起動しているはずです:

NAME        READY   STATUS    RESTARTS   AGE
fine-pod   1/1     Running   0          30s

新しいターミナルを開いて、http-echoからのシステムコールに関するログエントリをtailで監視しましょう:

# あなたのマシンのログは"/var/log/syslog"以外の場所にあるかもしれません。
tail -f /var/log/syslog | grep 'http-echo'

次のPodをNodePort Serviceで公開します:

kubectl expose pod fine-pod --type NodePort --port 5678

ノード上のServiceに割り当てられたポートを確認します:

kubectl get service fine-pod

出力は次のようになるでしょう:

NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
fine-pod    NodePort   10.111.36.142   <none>        5678:32373/TCP   72s

kindのコントロールプレーンコンテナの内部から、curlを用いてエンドポイントにアクセスします:

# 6a96207fed4bと32373を、それぞれ"docker ps"で確認したコンテナIDとポート番号に変更してください。
docker exec -it 6a96207fed4b curl localhost:32373

just made some syscalls!

syslogには何も出力されないはずです。なぜなら、このプロファイルは必要なシステムコールを全て許可しており、一覧にないシステムコールが呼び出された時にのみエラーを発生させるように構成しているためです。これはセキュリティの観点からすると理想的なシチュエーションといえますが、seccompプロファイルを作成するためのプログラムの解析には多少の労力が必要です。多くの労力を割かなくてもこれに近いセキュリティが得られるシンプルな手法があったなら、きっと素晴らしいものになるでしょう。

次のセクションに進む前にServiceとPodを削除します:

kubectl delete service fine-pod --wait
kubectl delete pod fine-pod --wait --now

全ワークロードに対する標準seccompプロファイルとして`RuntimeDefault`を使用する

FEATURE STATE: Kubernetes v1.27 [stable]

標準seccompプロファイルを指定するためには、この機能を利用したい全てのノードで--seccomp-defaultコマンドラインフラグを用いてkubeletを起動する必要があります。

この機能を有効化すると、kubeletはコンテナランタイムが定義するRuntimeDefaultのseccompプロファイルをデフォルトで使用するようになり、Unconfinedモード(seccomp無効化)になることはありません。コンテナランタイムが用意する標準プロファイルは、ワークロードの機能性を維持しつつ、強力な標準セキュリティルールの一式を用意することを目指しています。標準のプロファイルはコンテナランタイムやリリースバージョンによって異なる可能性があります。例えば、CRI-Oとcontainerdの標準プロファイルを比較してみるとよいでしょう。

備考:

この機能を有効化しても、PodやContainerなどのsecurityContext.seccompProfileフィールドは変更されず、非推奨のアノテーションがワークロードに追加されることもありません。したがって、ユーザーはワークロードの設定を変更せずにロールバックすることが可能です。 crictl inspectのようなツールを使うことで、コンテナがどのseccompプロファイルを利用しているのかを確認できます。

いくつかのワークロードでは、他のワークロードよりもシステムコール制限を少なくすることが必要な場合があります。つまり、RuntimeDefaultを適用する場合、こうしたワークロードの実行が失敗する可能性があります。このような障害を緩和するために、次のような対策を講じることができます:

ワークロードを明示的にUnconfinedとして稼働させる。
SeccompDefault機能をノードで無効化する。また、機能を無効化したノードに対してワークロードが配置されていることを確認しておく。
ワークロードを対象とするカスタムseccompプロファイルを作成する。

実運用環境に近いクラスターに対してこの機能を展開する場合、クラスター全体に対して変更をロールアウトする前に、一部ノードのみを対象にしてこのフィーチャーゲートを有効化し、ワークロードが実行できることを検証しておくことをお勧めします。

クラスターに対してとりうるアップグレード・ダウングレード戦略について更に詳細な情報を知りたい場合は、関連するKubernetes Enhancement Proposal (KEP)であるEnable seccomp by defaultを参照してください。

Kubernetes 1.34では、specで特定のseccompプロファイルを指定していないPodに対して、デフォルトで適用するseccompプロファイルを設定することができます。ただし、この標準seccompプロファイルを利用する場合、対象とする全ノードでこの機能を有効化しておく必要があります。

稼働中のKubernetes 1.34クラスターでこの機能を有効化する場合、kubeletに--seccomp-defaultコマンドラインフラグを付与して起動するか、Kubernetesの設定ファイルでこの機能を有効化する必要があります。このフィーチャーゲートをkindで有効化する場合、kindが最低限必要なKubernetesバージョンを満たしていて、かつkindの設定ファイルでSeccompDefaultを有効化してください:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
    kubeadmConfigPatches:
      - |
        kind: JoinConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            seccomp-default: "true"        
  - role: worker
    image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
    kubeadmConfigPatches:
      - |
        kind: JoinConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            seccomp-default: "true"

クラスターの準備ができたら、Podを実行します:

kubectl run --rm -it --restart=Never --image=alpine alpine -- sh

このコマンドで標準のseccompプロファイルを紐付けられるはずです。この結果を確認するには、docker exec経由でcrictl inspectを実行することで、kindワーカー上のコンテナを確認します:

docker exec -it kind-worker bash -c \
    'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp'

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"],
  "syscalls": [
    {
      "names": ["..."]
    }
  ]
}

次の項目

Linuxのseccompについて更に学びたい場合は、次の記事を参考にすると良いでしょう:

最終更新 July 30, 2025 at 12:18 AM PST: [ja] translate content/ja/docs/tutorials/security/seccomp.md (#51569) (046f957753)

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

目標

始める前に

備考:

サンプルのseccompプロファイルをダウンロードする

kindでローカルKubernetesクラスターを構築する

コンテナランタイムの標準seccompプロファイルを利用してPodを作成する

備考:

システムコール監査のためのseccompプロファイルを利用してPodを作成する

備考:

違反が発生するseccompプロファイルでPodを作成する

必要なシステムコールのみを許可するseccompプロファイルを用いてPodを作成する

全ワークロードに対する標準seccompプロファイルとしてRuntimeDefaultを使用する

備考:

次の項目

フィードバック

全ワークロードに対する標準seccompプロファイルとして`RuntimeDefault`を使用する