Seccomp 與 Kubernetes

Seccomp 代表安全運算模式，自 2.6.12 版起一直是 Linux 核心的一項功能。它可用於沙箱化程序的權限，限制程序從使用者空間呼叫到核心的能力。Kubernetes 可讓您自動將載入到節點上的 seccomp 設定檔套用至您的 Pod 和容器。

Seccomp 欄位

有四種方式可以為pod指定 seccomp 設定檔

• 針對整個 Pod，使用 spec.securityContext.seccompProfile
• 針對單一容器，使用 spec.containers[*].securityContext.seccompProfile
• 針對 (可重新啟動/Sidecar) init 容器，使用 spec.initContainers[*].securityContext.seccompProfile
• 針對臨時容器，使用 spec.ephemeralContainers[*].securityContext.seccompProfile

pods/security/seccomp/fields.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
  ephemeralContainers:
  - name: ephemeral-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  initContainers:
  - name: init-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  containers:
  - name: container
    image: docker.io/library/debian:stable
    securityContext:
      seccompProfile:
        type: Localhost
        localhostProfile: my-profile.json

上述範例中的 Pod 以 Unconfined 執行，而 ephemeral-container 和 init-container 明確定義 RuntimeDefault。如果臨時或 init 容器未明確設定 securityContext.seccompProfile 欄位，則該值將從 Pod 繼承。這同樣適用於執行 Localhost 設定檔 my-profile.json 的容器。

一般而言，(臨時) 容器中的欄位優先順序高於 Pod 層級的值，而未設定 seccomp 欄位的容器則從 Pod 繼承設定檔。

以下是 seccompProfile.type 可能的值

Unconfined

工作負載在沒有任何 seccomp 限制的情況下執行。

RuntimeDefault

套用由容器執行期定義的預設 seccomp 設定檔。預設設定檔旨在提供強大的安全預設值，同時保留工作負載的功能。預設設定檔在不同的容器執行期及其發行版本之間可能有所不同，例如比較 CRI-O 和 containerd 的設定檔。

Localhost

將套用 localhostProfile，該設定檔必須在節點磁碟上可用 (在 Linux 上為 /var/lib/kubelet/seccomp)。seccomp 設定檔的可用性由容器執行期在容器建立時驗證。如果設定檔不存在，則容器建立將失敗並顯示 CreateContainerError。

Localhost 設定檔

Seccomp 設定檔是 JSON 檔案，遵循 OCI 執行期規格定義的結構描述。設定檔基本上定義了基於比對的系統呼叫的動作，但也允許傳遞特定值作為系統呼叫的引數。例如

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 38,
  "syscalls": [
    {
      "names": [
        "adjtimex",
        "alarm",
        "bind",
        "waitid",
        "waitpid",
        "write",
        "writev"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

上述設定檔中的 defaultAction 定義為 SCMP_ACT_ERRNO，並將作為後備傳回至 syscalls 中定義的動作。錯誤透過 defaultErrnoRet 欄位定義為代碼 38。

以下動作通常是可能的

SCMP_ACT_ERRNO

傳回指定的錯誤代碼。

SCMP_ACT_ALLOW

允許執行系統呼叫。

SCMP_ACT_KILL_PROCESS

終止程序。

SCMP_ACT_KILL_THREAD 和 SCMP_ACT_KILL

僅終止執行緒。

SCMP_ACT_TRAP

擲回 SIGSYS 訊號。

SCMP_ACT_NOTIFY 和 SECCOMP_RET_USER_NOTIF。

通知使用者空間。

SCMP_ACT_TRACE

使用指定的值通知追蹤程序。

SCMP_ACT_LOG

在動作記錄到 syslog 或 auditd 後，允許執行系統呼叫。

某些動作 (例如 SCMP_ACT_NOTIFY 或 SECCOMP_RET_USER_NOTIF) 可能不受支援，具體取決於使用的容器執行期、OCI 執行期或 Linux 核心版本。也可能存在更多限制，例如 SCMP_ACT_NOTIFY 不能用作 defaultAction 或用於某些系統呼叫 (例如 write)。所有這些限制都由 OCI 執行期 (runc、crun) 或 libseccomp 定義。

syscalls JSON 陣列包含物件的清單，這些物件依其各自的 names 參考系統呼叫。例如，動作 SCMP_ACT_ALLOW 可用於建立允許系統呼叫的白名單，如上述範例中所述。也可以使用動作 SCMP_ACT_ERRNO 定義另一個清單，但傳回 (errnoRet) 值不同。

也可以指定傳遞至某些系統呼叫的引數 (args)。有關這些進階使用案例的更多資訊，請參閱 OCI 執行期規格和 Seccomp Linux 核心文件。

延伸閱讀

• 使用 seccomp 限制容器的系統呼叫
• Pod 安全標準