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

Kubernetes 1.23：Pod 安全性升級至 Beta 版

作者：Jim Angel (Google), Lachlan Evenson (Microsoft) | 2021年12月9日星期四

隨著 Kubernetes v1.23 的發布，Pod Security admission 現已進入 Beta 階段。Pod Security 是一個內建的 admission controller，它會根據預定義的 Pod Security Standards 評估 Pod 規格，並決定是否 admit 或 deny Pod 執行。

Pod Security 是 PodSecurityPolicy 的後繼者，PodSecurityPolicy 已在 v1.21 版本中被棄用，並將在 Kubernetes v1.25 中移除。在本文中，我們將介紹 Pod Security 的關鍵概念以及如何使用它。我們希望叢集管理員和開發人員都能使用這個新機制，為他們的工作負載強制執行安全的預設設定。

為何使用 Pod Security

Pod Security 的總體目標是讓您可以隔離工作負載。您可以運行一個運行不同工作負載的叢集，並且無需添加額外的第三方工具，即可實施控制，要求工作負載的 Pod 將其自身的權限限制在定義的邊界集合內。

Pod Security 克服了 Kubernetes 現有但已棄用的 PodSecurityPolicy (PSP) 機制的關鍵缺點

政策授權模型 — 使用控制器部署具有挑戰性。
切換的風險 — 缺乏 dry-run/audit 功能使得啟用 PodSecurityPolicy 變得困難。
不一致且無界限的 API — 龐大的配置介面和不斷變化的約束導致了複雜且令人困惑的 API。

PSP 的缺點使其非常難以使用，這導致社群重新評估是否可以透過更好的實作來實現相同的目標。其中一個目標是提供開箱即用的解決方案來應用安全性最佳實務。Pod Security 隨附預定義的 Pod Security 等級，叢集管理員可以配置這些等級以滿足所需的安全性態勢。

重要的是要注意，Pod Security 並不完全具備與已棄用的 PodSecurityPolicy 相同的功能對等性。具體來說，它不具備 mutate 或更改 Kubernetes 資源以代表使用者自動修復政策違規的能力。此外，它不提供對 Pod 規格或您可能希望評估的任何其他 Kubernetes 資源中每個允許的欄位和值的細粒度控制。如果您需要更細粒度的政策控制，請查看這些其他專案，這些專案支援此類使用案例。

Pod Security 也遵守 Kubernetes 宣告式物件管理的最佳實務，方法是拒絕違反政策的資源。這要求在部署到 Kubernetes 之前，必須在原始碼儲存庫中更新資源，並更新工具。

Pod Security 如何運作？

Pod Security 是一個內建的 admission controller，從 Kubernetes v1.22 開始提供，但也可以作為獨立的 webhook 運行。Admission controller 的功能是在 Kubernetes API server 中攔截請求，然後再持久化到儲存。它們可以 admit 或 deny 請求。在 Pod Security 的情況下，Pod 規格將根據以 Pod Security Standard 形式配置的政策進行評估。這表示 Pod 規格中對安全性敏感的欄位將僅允許具有特定值。

配置 Pod Security

Pod Security Standards

為了使用 Pod Security，我們首先需要了解 Pod Security Standards。這些標準定義了三個不同的政策等級，從寬鬆到嚴格不等。這些等級如下

privileged — 開放且無限制
baseline — 涵蓋已知的權限提升，同時最大限度地減少限制
restricted — 高度限制，加強防禦已知和未知的權限提升。可能導致相容性問題

這些政策等級中的每一個都定義了 Pod 規格中哪些欄位受到限制以及允許的值。這些政策限制的一些欄位包括

spec.securityContext.sysctls
spec.hostNetwork
spec.volumes[*].hostPath
spec.containers[*].securityContext.privileged

政策等級透過 Namespace 資源上的標籤應用，這允許針對每個命名空間進行細緻的政策選擇。API server 中的 AdmissionConfiguration 也可以配置為設定叢集範圍的預設等級和豁免。

政策模式

政策以特定模式應用。可以在同一個命名空間上設定多種模式（具有不同的政策等級）。以下是模式列表

enforce — 任何違反政策的 Pod 都將被拒絕
audit — 違規行為將記錄為稽核日誌中的註解，但不影響是否允許 Pod。
warn — 違規行為將向使用者發送警告訊息，但不影響是否允許 Pod。

除了模式之外，您還可以將政策釘選到特定版本（例如 v1.22）。如果政策定義在未來的 Kubernetes 版本中發生變更，釘選到特定版本可讓行為保持一致。

實作示範

先決條件

KinD
kubectl
Docker 或 Podman 容器運行時 & CLI

部署 kind 叢集

kind create cluster --image kindest/node:v1.23.0

啟動可能需要一些時間，一旦啟動，節點可能需要一分鐘左右才能準備就緒。

kubectl cluster-info --context kind-kind

等待節點 STATUS 變為 ready。

kubectl get nodes

輸出類似於此

NAME                 STATUS   ROLES                  AGE   VERSION
kind-control-plane   Ready    control-plane,master   54m   v1.23.0

確認 Pod Security 已啟用

確認 API 預設啟用外掛程式的最佳方法是檢查 Kubernetes API 容器的說明引數。

kubectl -n kube-system exec kube-apiserver-kind-control-plane -it -- kube-apiserver -h | grep "default enabled ones"

輸出類似於此

...
      --enable-admission-plugins strings
admission plugins that should be enabled in addition
to default enabled ones (NamespaceLifecycle, LimitRanger,
ServiceAccount, TaintNodesByCondition, PodSecurity, Priority,
DefaultTolerationSeconds, DefaultStorageClass,
StorageObjectInUseProtection, PersistentVolumeClaimResize,
RuntimeClass, CertificateApproval, CertificateSigning,
CertificateSubjectRestriction, DefaultIngressClass,
MutatingAdmissionWebhook, ValidatingAdmissionWebhook,
ResourceQuota).
...

PodSecurity 列在預設啟用的 admission 外掛程式群組中。

如果使用雲端供應商，或者如果您無法存取 API server，則最佳的檢查方法是運行快速的端對端測試

kubectl create namespace verify-pod-security
kubectl label namespace verify-pod-security pod-security.kubernetes.io/enforce=restricted
# The following command does NOT create a workload (--dry-run=server)
kubectl -n verify-pod-security run test --dry-run=server --image=busybox --privileged
kubectl delete namespace verify-pod-security

輸出類似於此

Error from server (Forbidden): pods "test" is forbidden: violates PodSecurity "restricted:latest": privileged (container "test" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

配置 Pod Security

政策透過標籤應用於命名空間。這些標籤如下

pod-security.kubernetes.io/<MODE>: <LEVEL> (啟用 pod security 必需)
pod-security.kubernetes.io/<MODE>-version: <VERSION> (選用，預設為最新版本)

可以為每個強制執行模式提供特定版本。版本將政策釘選到作為 Kubernetes 版本一部分發布的版本。釘選到特定 Kubernetes 版本允許確定性的政策行為，同時允許未來更新 Pod Security Standards 的彈性。可能的 <MODE(S)> 為 enforce、audit 和 warn。

何時使用 `warn`？

warn 的典型用途是為未來的變更做好準備，您希望在其中強制執行不同的政策。最常見的兩種情況是

warn 與 enforce 相同的等級但不同的版本 (例如，將 enforce 釘選到 restricted+v1.23，並將 warn 設定為 restricted+latest)
warn 比 enforce 更嚴格的等級 (例如，enforce baseline，warn restricted)

不建議對與 enforce 政策完全相同的等級+版本使用 warn。在 admission 序列中，如果 enforce 失敗，則整個序列會在評估 warn 之前失敗。

首先，如果尚未建立命名空間，請建立一個名為 verify-pod-security 的命名空間。對於示範，標記時使用 --overwrite 以允許將單個命名空間重新用於多個範例。

kubectl create namespace verify-pod-security

部署示範工作負載

每個工作負載代表更高的安全性等級，該等級將無法通過後續的 profile。

對於以下範例，請使用 busybox 容器運行 100 萬秒（≅11 天）的 sleep 命令，或直到刪除為止。Pod Security 對您選擇哪個容器映像不感興趣，而是對 Pod 等級設定及其對安全性的影響感興趣。

Privileged 等級和工作負載

對於 privileged pod，請使用 privileged 政策。這允許容器內的進程獲得新的進程（也稱為「權限提升」），如果不受信任，可能會很危險。

首先，讓我們應用 restricted Pod Security 等級進行測試。

# enforces a "restricted" security policy and audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted

接下來，嘗試在命名空間中部署 privileged 工作負載。

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
EOF

輸出類似於此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-privileged" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

現在讓我們應用 privileged Pod Security 等級，然後重試。

# enforces a "privileged" security policy and warns / audits on baseline
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=privileged \
  pod-security.kubernetes.io/warn=baseline \
  pod-security.kubernetes.io/audit=baseline

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
EOF

輸出類似於此

pod/busybox-privileged created

我們可以運行 kubectl -n verify-pod-security get pods 來驗證它是否正在運行。使用以下命令清理

kubectl -n verify-pod-security delete pod busybox-privileged

Baseline 等級和工作負載

baseline 政策示範了合理的預設值，同時防止常見的容器漏洞。

讓我們恢復為 restricted Pod Security 等級以進行快速測試。

# enforces a "restricted" security policy and audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted

應用工作負載。

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-baseline
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
          - CHOWN
EOF

輸出類似於此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-baseline" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]; container "busybox" must not include "CHOWN" in securityContext.capabilities.add), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

讓我們應用 baseline Pod Security 等級，然後重試。

# enforces a "baseline" security policy and warns / audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-baseline
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
          - CHOWN
EOF

輸出類似於以下內容。請注意，警告與上面測試中的錯誤訊息相符，但 pod 仍然成功建立。

Warning: would violate PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]; container "busybox" must not include "CHOWN" in securityContext.capabilities.add), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/busybox-baseline created

請記住，我們已將 verify-pod-security 命名空間設定為基於 restricted profile 的 warn。我們可以運行 kubectl -n verify-pod-security get pods 來驗證它是否正在運行。使用以下命令清理

kubectl -n verify-pod-security delete pod busybox-baseline

Restricted 等級和工作負載

restricted 政策要求拒絕所有 privileged 參數。它是最安全的，但會犧牲複雜性。restricted 政策僅允許容器新增 NET_BIND_SERVICE 功能。

雖然我們已經測試了 restricted 作為封鎖功能，但讓我們嘗試運行一些符合所有條件的東西。

首先，我們需要最後一次重新應用 restricted profile。

# enforces a "restricted" security policy and audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-restricted
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
EOF

輸出類似於此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-restricted" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

這是因為 restricted profile 明確要求將某些值設定為最安全的參數。

透過要求明確的值，manifests 變得更具宣告性，並且您的整個安全模型可以左移。透過 restricted 強制執行等級，公司可以根據允許的 manifests 稽核其叢集的合規性。

讓我們修正每個警告，產生以下檔案

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-restricted
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      seccompProfile:
        type: RuntimeDefault
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE
EOF

輸出類似於此

pod/busybox-restricted created

運行 kubectl -n verify-pod-security get pods 來驗證它是否正在運行。輸出類似於此

NAME               READY   STATUS                       RESTARTS   AGE
busybox-restricted   0/1     CreateContainerConfigError   0          2m26s

讓我們找出容器為何無法使用 kubectl -n verify-pod-security describe pod busybox-restricted 啟動的原因。輸出類似於此

Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Warning  Failed     2m29s (x8 over 3m55s)  kubelet            Error: container has runAsNonRoot and image will run as root (pod: "busybox-restricted_verify-pod-security(a4c6a62d-2166-41a9-b288-20df17cf5c90)", container: busybox)

為了解决這個問題，請將有效 UID (runAsUser) 設定為非零 (root) 值，或使用 nobody UID (65534)。

# delete the original pod
kubectl -n verify-pod-security delete pod busybox-restricted

# create the pod again with new runAsUser
cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-restricted
spec:
  securityContext:
    runAsUser: 65534
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      seccompProfile:
        type: RuntimeDefault
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE
EOF

運行 kubectl -n verify-pod-security get pods 來驗證它是否正在運行。輸出類似於此

NAME                 READY   STATUS    RESTARTS   AGE
busybox-restricted   1/1     Running   0          25s

使用以下命令清理示範 (restricted pod 和命名空間)

kubectl delete namespace verify-pod-security

此時，如果您想更深入地研究 linux 權限或特定容器允許的內容，請 exec 到控制平面並使用 containerd 和 crictl inspect 進行實驗。

# if using docker, shell into the control plane
docker exec -it kind-control-plane bash

# list running containers
crictl ps

# inspect each one by container ID
crictl inspect <CONTAINER ID>

應用叢集範圍的政策

除了將標籤應用於命名空間以配置政策之外，您還可以透過使用 AdmissionConfiguration 資源來配置叢集範圍的政策和豁免。

使用此資源，預設情況下，政策定義將應用於整個叢集，並且透過命名空間標籤應用的任何政策都將優先。

AdmissionConfiguration 配置檔案沒有運行時可配置的 API，因此叢集管理員需要透過 API server 上的 --admission-control-config-file 標誌指定檔案的路徑。

在以下資源中，我們正在強制執行 baseline 政策，並警告和稽核 baseline 政策。我們也正在將 kube-system 命名空間豁免於此政策。

不建議在安裝後變更控制平面/叢集，因此讓我們使用所有命名空間上的預設政策建立一個新叢集。

首先，刪除目前的叢集。

kind delete cluster

建立 Pod Security 配置，該配置 enforce 和 audit baseline 政策，同時使用 restricted profile 來 warn 最終使用者。

cat <<EOF > pod-security.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1beta1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "baseline"
      enforce-version: "latest"
      audit: "baseline"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: [kube-system]
EOF

如需其他選項，請查看官方 standards admission controller 文件。

我們現在有一個預設的 baseline 政策。接下來將其傳遞給 kind 配置，以啟用 --admission-control-config-file API server 引數並傳遞政策檔案。若要將檔案傳遞到 kind 叢集，請使用配置檔案來傳遞其他設定指示。Kind 使用 kubeadm 來佈建叢集，並且配置檔案能夠傳遞 kubeadmConfigPatches 以進行進一步的自訂。在我們的案例中，本機檔案被掛載到控制平面節點中作為 /etc/kubernetes/policies/pod-security.yaml，然後掛載到 apiServer 容器中。我們也傳遞了指向政策位置的 --admission-control-config-file 引數。

cat <<EOF > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: ClusterConfiguration
    apiServer:
        # enable admission-control-config flag on the API server
        extraArgs:
          admission-control-config-file: /etc/kubernetes/policies/pod-security.yaml
        # mount new file / directories on the control plane
        extraVolumes:
          - name: policies
            hostPath: /etc/kubernetes/policies
            mountPath: /etc/kubernetes/policies
            readOnly: true
            pathType: "DirectoryOrCreate"
  # mount the local file on the control plane
  extraMounts:
  - hostPath: ./pod-security.yaml
    containerPath: /etc/kubernetes/policies/pod-security.yaml
    readOnly: true
EOF

使用上面定義的 kind 配置檔案建立新叢集。

kind create cluster --image kindest/node:v1.23.0 --config kind-config.yaml

讓我們看看預設命名空間。

kubectl describe namespace default

輸出類似於此

Name:         default
Labels:       kubernetes.io/metadata.name=default
Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource.

讓我們建立一個新的命名空間，看看標籤是否應用於該命名空間。

kubectl create namespace test-defaults
kubectl describe namespace test-defaults

相同。

Name:         test-defaults
Labels:       kubernetes.io/metadata.name=test-defaults
Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource.

可以部署 privileged 工作負載嗎？

cat <<EOF | kubectl -n test-defaults apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
EOF

嗯... 可以。至少預設的 warn 等級正在運作。

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/busybox-privileged created

讓我們使用 kubectl -n test-defaults delete pod/busybox-privileged 刪除 pod。

我的配置甚至在運作嗎？

# if using docker, shell into the control plane
docker exec -it kind-control-plane bash

# cat out the file we mounted
cat /etc/kubernetes/policies/pod-security.yaml

# check the api server logs
cat /var/log/containers/kube-apiserver*.log 

# check the api server config
cat /etc/kubernetes/manifests/kube-apiserver.yaml

更新： baseline 政策允許 allowPrivilegeEscalation。雖然我看不到 Pod Security 預設的強制執行等級，但它們確實存在。讓我們嘗試提供一個違反 baseline 的 manifest，方法是請求 hostNetwork 存取權。

# delete the original pod
kubectl -n test-defaults delete pod busybox-privileged

cat <<EOF | kubectl -n test-defaults apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
  hostNetwork: true
EOF

輸出類似於此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-privileged" is forbidden: violates PodSecurity "baseline:latest": host namespaces (hostNetwork=true)

成功了！！！🎉🎉🎉

我稍後發現，檢查事物是否按預期運作的另一種方法是檢查原始 API server 指標端點。

運行以下命令

kubectl get --raw /metrics | grep pod_security_evaluations_total

輸出類似於此

# HELP pod_security_evaluations_total [ALPHA] Number of policy evaluations that occurred, not counting ignored or exempt requests.
# TYPE pod_security_evaluations_total counter
pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 2
pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="privileged",policy_version="latest",request_operation="create",resource="pod",subresource=""} 0
pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="privileged",policy_version="latest",request_operation="update",resource="pod",subresource=""} 0
pod_security_evaluations_total{decision="deny",mode="audit",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 1
pod_security_evaluations_total{decision="deny",mode="enforce",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 1
pod_security_evaluations_total{decision="deny",mode="warn",policy_level="restricted",policy_version="latest",request_operation="create",resource="controller",subresource=""} 2
pod_security_evaluations_total{decision="deny",mode="warn",policy_level="restricted",policy_version="latest",request_operation="create",resource="pod",subresource=""} 2

監控工具也可以擷取這些指標以進行報告、評估或衡量趨勢。

清理

完成後，刪除 kind 叢集。

kind delete cluster

稽核

稽核是追蹤叢集中正在強制執行哪些政策的另一種方法。若要使用 kind 設定稽核，請查看官方文件以了解啟用稽核。截至版本 1.11，Kubernetes 稽核日誌包含兩個註解，指示請求是否已授權 (authorization.k8s.io/decision) 以及決策的原因 (authorization.k8s.io/reason)。稽核事件可以串流到 webhook 以進行監控、追蹤或警報。

稽核事件看起來與以下內容類似

{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"","pod-security.kubernetes.io/audit":"allowPrivilegeEscalation != false (container \"busybox\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"busybox\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"busybox\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"busybox\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"}}

稽核也是評估您的叢集目前是否符合 Pod Security 的良好第一步。Kubernetes Enhancement Proposal (KEP) 暗示未來 baseline 可能是未標記命名空間的預設值。

針對 Pod Security 事件調整的範例 audit-policy.yaml 配置

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
    - group: "" # core API group
      resources: ["pods", "pods/ephemeralcontainers", "podtemplates", "replicationcontrollers"]
    - group: "apps"
      resources: ["daemonsets", "deployments", "replicasets", "statefulsets"]
    - group: "batch"
      resources: ["cronjobs", "jobs"]
  verbs: ["create", "update"]
  omitStages:
    - "RequestReceived"
    - "ResponseStarted"
    - "Panic"

啟用稽核後，如果使用 --audit-log-path，請查看配置的本機檔案，如果使用 --audit-webhook-config-file，則查看 webhook 的目的地。

如果使用檔案 (--audit-log-path)，請運行 cat /PATH/TO/API/AUDIT.log | grep "is forbidden:" 以查看所有被拒絕的已稽核工作負載。

PSP 遷移

如果您已經在使用 PSP，SIG Auth 建立了一個指南，並發布了從 PSP 遷移的步驟。

總結流程

將所有現有的 PSP 更新為非 mutate
在 warn 或 audit 模式下應用 Pod Security 政策
將 Pod Security 政策升級到 enforce 模式
從 --enable-admission-plugins 中移除 PodSecurityPolicy

SIG Auth 已開始考慮提供一個工具來協助遷移，這被列為「選用的未來擴展」，目前超出範圍。更多 KEP 中的詳細資訊。

總結

Pod Security 是一項很有前景的新功能，它提供了一種開箱即用的方法，讓使用者可以提高其工作負載的安全性態勢。與任何已成熟為 Beta 版的新增強功能一樣，我們要求您試用它、提供回饋，或透過提出 Github issue 或加入 SIG Auth 社群會議來分享您的經驗。我們希望 Pod Security 將部署在每個叢集上，以作為我們社群持續追求將 Kubernetes 安全性作為優先事項的努力。

有關如何使用 Pod Security Admission 功能啟用「baseline」Pod Security Standards 的逐步指南，請參閱這些專門的教學課程，其中涵蓋了叢集層級和命名空間層級所需的配置。

Kubernetes 部落格

Kubernetes 1.23：Pod 安全性升級至 Beta 版

為何使用 Pod Security

Pod Security 如何運作？

配置 Pod Security

Pod Security Standards

政策模式

實作示範

先決條件

部署 kind 叢集

確認 Pod Security 已啟用

配置 Pod Security

何時使用 `warn`？

部署示範工作負載

Privileged 等級和工作負載

Baseline 等級和工作負載

Restricted 等級和工作負載

應用叢集範圍的政策

成功了！！！🎉🎉🎉

清理

稽核

PSP 遷移

總結

其他資源

Kubernetes 1.23：Pod 安全性升級至 Beta 版

為何使用 Pod Security

Pod Security 如何運作？

配置 Pod Security

Pod Security Standards

政策模式

實作示範

先決條件

部署 kind 叢集

確認 Pod Security 已啟用

配置 Pod Security

何時使用 warn？

部署示範工作負載

Privileged 等級和工作負載

Baseline 等級和工作負載

Restricted 等級和工作負載

應用叢集範圍的政策

成功了！！！🎉🎉🎉

清理

稽核

PSP 遷移

總結

其他資源

何時使用 `warn`？