本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

使用 OCI 構件來發布 seccomp、SELinux 和 AppArmor 的安全設定檔

Security Profiles Operator (SPO) 使在 Kubernetes 中管理 seccomp、SELinux 和 AppArmor 設定檔比以往更容易。它允許叢集管理員在預定義的自訂資源 YAML 中定義設定檔,然後由 SPO 將其分發到整個叢集中。安全性設定檔的修改和移除也以相同方式由運算子管理,但這只是其功能的一小部分。

SPO 的另一個核心功能是能夠堆疊 seccomp 設定檔。這表示使用者可以在 YAML 規格中定義 baseProfileName,然後由運算子自動解析並組合系統呼叫規則。如果基礎設定檔具有另一個 baseProfileName,則運算子將以遞迴方式解析設定檔,直到達到特定深度。常見的使用案例是為低階容器運行時 (例如 runccrun) 定義基礎設定檔,其中包含在任何情況下執行容器所需的系統呼叫。或者,應用程式開發人員可以為其標準發行容器定義 seccomp 基礎設定檔,並在其上堆疊用於應用程式邏輯的專用設定檔。這樣,開發人員可以專注於維護更簡單且範圍限定於應用程式邏輯的 seccomp 設定檔,而無需考慮整個基礎架構設定。

但是如何維護這些基礎設定檔呢?例如,運行時所需的系統呼叫數量可能會在其發行週期內發生變化,就像主要應用程式一樣。基礎設定檔必須在同一個叢集中可用,否則主要 seccomp 設定檔將無法部署。這表示它們與主要應用程式設定檔緊密耦合,這與基礎設定檔的主要概念背道而馳。將它們作為純檔案分發和管理感覺像是需要解決的額外負擔。

OCI 構件來救援

Security Profiles Operator 的 v0.8.0 版本支援將基礎設定檔作為 OCI 構件進行管理!將 OCI 構件想像為輕量級容器映像,以與映像相同的方式將檔案儲存在層中,但沒有要執行的程序。這些構件可用於在相容的登錄檔中儲存安全性設定檔,就像常規容器映像一樣。這表示它們可以像常規容器映像一樣進行版本控制、命名空間化和註釋。

若要查看其運作方式,請在 seccomp 設定檔 CRD 中指定以 oci:// 為前綴的 baseProfileName,例如

apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  name: test
spec:
  defaultAction: SCMP_ACT_ERRNO
  baseProfileName: oci://ghcr.io/security-profiles/runc:v1.1.5
  syscalls:
    - action: SCMP_ACT_ALLOW
      names:
        - uname

運算子將負責使用 oras 提取內容,以及驗證構件的 sigstore (cosign) 簽名。如果構件未簽名,則 SPO 將拒絕它們。然後,產生的設定檔 test 將包含來自遠端 runc 設定檔的所有基礎系統呼叫,以及額外允許的 uname 系統呼叫。也可以透過其摘要 (SHA256) 引用基礎設定檔,使要提取的構件更具體,例如透過引用 oci://ghcr.io/security-profiles/runc@sha256:380…

運算子在內部快取提取的構件長達 24 小時,最多 1000 個設定檔,這表示如果在該時間段之後、快取已滿或運算子守護程序重新啟動,它們將會重新整理。

由於整體產生的系統呼叫對使用者隱藏 (我只在 SeccompProfile 中列出了 baseProfileName,而不是系統呼叫本身),因此我還將使用最終的 syscalls 註釋該 SeccompProfile。

以下是註釋後 SeccompProfile 的外觀

> kubectl describe seccompprofile test
Name:         test
Namespace:    security-profiles-operator
Labels:       spo.x-k8s.io/profile-id=SeccompProfile-test
Annotations:  syscalls:
                [{"names":["arch_prctl","brk","capget","capset","chdir","clone","close",...
API Version:  security-profiles-operator.x-k8s.io/v1beta1

SPO 維護人員在 「Security Profiles」GitHub 組織中提供所有公開基礎設定檔。

管理 OCI 安全性設定檔

好的,現在官方 SPO 提供了一堆基礎設定檔,但我該如何定義自己的設定檔呢?嗯,首先我們必須選擇一個可運作的登錄檔。已經有很多登錄檔支援 OCI 構件

Security Profiles Operator 隨附了一個名為 spoc 的新命令列介面,它是一個用於管理 OCI 設定檔的小型輔助工具,同時還執行此部落格文章範圍之外的各種其他操作。但是,命令 spoc push 可用於將安全性設定檔推送到登錄檔

> export USERNAME=my-user
> export PASSWORD=my-pass
> spoc push -f ./examples/baseprofile-crun.yaml ghcr.io/security-profiles/crun:v1.8.3
16:35:43.899886 Pushing profile ./examples/baseprofile-crun.yaml to: ghcr.io/security-profiles/crun:v1.8.3
16:35:43.899939 Creating file store in: /tmp/push-3618165827
16:35:43.899947 Adding profile to store: ./examples/baseprofile-crun.yaml
16:35:43.900061 Packing files
16:35:43.900282 Verifying reference: ghcr.io/security-profiles/crun:v1.8.3
16:35:43.900310 Using tag: v1.8.3
16:35:43.900313 Creating repository for ghcr.io/security-profiles/crun
16:35:43.900319 Using username and password
16:35:43.900321 Copying profile to repository
16:35:46.976108 Signing container image
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.

By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=…
Successfully verified SCT...
tlog entry created with index: 16520520
Pushing signature to: ghcr.io/security-profiles/crun

您可以看到該工具會自動簽署構件,並將 ./examples/baseprofile-crun.yaml 推送到登錄檔,然後可以直接在 SPO 中使用。如果需要使用者名稱和密碼驗證,請使用 --username-u 標誌或匯出 USERNAME 環境變數。若要設定密碼,請匯出 PASSWORD 環境變數。

可以使用 --annotations / -a 標誌多次以 KEY:VALUE 格式將自訂註釋新增至安全性設定檔。這些目前沒有任何作用,但在稍後的某些時候,運算子的其他功能可能會依賴它們。

spoc 用戶端也能夠從與 OCI 構件相容的登錄檔中提取安全性設定檔。若要執行此操作,只需執行 spoc pull

> spoc pull ghcr.io/security-profiles/runc:v1.1.5
16:32:29.795597 Pulling profile from: ghcr.io/security-profiles/runc:v1.1.5
16:32:29.795610 Verifying signature

Verification for ghcr.io/security-profiles/runc:v1.1.5 --
The following checks were performed on each of these signatures:
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

[{"critical":{"identity":{"docker-reference":"ghcr.io/security-profiles/runc"},…}}]
16:32:33.208695 Creating file store in: /tmp/pull-3199397214
16:32:33.208713 Verifying reference: ghcr.io/security-profiles/runc:v1.1.5
16:32:33.208718 Creating repository for ghcr.io/security-profiles/runc
16:32:33.208742 Using tag: v1.1.5
16:32:33.208743 Copying profile from repository
16:32:34.119652 Reading profile
16:32:34.119677 Trying to unmarshal seccomp profile
16:32:34.120114 Got SeccompProfile: runc-v1.1.5
16:32:34.120119 Saving profile in: /tmp/profile.yaml

現在可以在 /tmp/profile.yaml 或指定的輸出檔案 --output-file / -o 中找到該設定檔。我們可以像 spoc push 一樣指定使用者名稱和密碼。

spoc 使管理作為 OCI 構件的安全性設定檔變得容易,然後可以直接由運算子本身使用。

這就是我們對 Security Profiles Operator 最新可能性的簡潔旅程!如果您對更多資訊感興趣、提供意見回饋或尋求協助,請隨時透過 Slack (#security-profiles-operator)郵寄清單 直接與我們聯繫。