在使用前，需要先了解Kubernetes的。Pod安全性標準（Security Standards） 為 Pod 定義了不同的安全性策略級別。這些標準能夠讓你以一種清晰、一致的方式定義如何限制Pod行為。而Pod Security Admission則是這些安全性標準的控制器，用于在創建Pod時執行定義好的安全限制。
Pod安全性標準定義了三種安全性策略級別：
表 Pod安全性策略級別
| 策略級別（level） | 描述 |
|---|---|
| privileged | 不受限制，通常適用于特權較高、受信任的用戶所管理的系統級或基礎設施級負載，例如CNI、存儲驅動等。 |
| baseline | 限制較弱但防止已知的特權提升（Privilege Escalation），通常適用于部署常用的非關鍵性應用負載，該策略將禁止使用hostNetwork、hostPID等能力。 |
| restricted | 嚴格限制，遵循Pod防護的最佳實踐。 |
Pod Security Admission配置是命名空間級別的，控制器將會對該命名空間下Pod或容器中的安全上下文（Security Context）以及其他參數進行限制。其中，privileged策略將不會對Pod和Container配置中的securityContext字段有任何校驗，而Baseline和Restricted則會對securityContext字段有不同的取值要求，具體規范請參見。
關于如何在Pod或容器中設置Security Context，請參見。
Pod Security Admission標簽
Kubernetes為Pod Security Admission定義了三種標簽，您可以在某個命名空間中設置這些標簽來定義需要使用的Pod安全性標準級別，但請勿在kube-system等系統命名空間修改Pod安全性標準級別，否則可能導致系統命名空間下Pod故障。
表 Pod Security Admission標簽
| 隔離模式（mode） | 生效對象 | 描述 |
|---|---|---|
| enforce | Pod | 違反指定策略會導致Pod無法創建。 |
| audit | 工作負載（例如Deployment、Job等） | 違反指定策略會在審計日志（audit log）中添加新的審計事件，Pod可以被創建。 |
| warn | 工作負載（例如Deployment、Job等） | 違反指定策略會返回用戶可見的告警信息，Pod可以被創建。 |
說明Pod通常是通過創建Deployment或Job這類工作負載對象來間接創建的。在使用Pod Security Admission時，audit或warn模式的隔離都將在工作負載級別生效，而enforce模式并不會應用到工作負載，僅在Pod上生效。
使用命名空間標簽進行Pod Security Admission配置
您可以在不同的隔離模式中應用不同的策略，由于Pod安全性準入能力是在命名空間（Namespace）級別實現的，因此假設某個Namespace配置如下：
apiVersion: v1
kind: Namespace
metadata:
name: my-baseline-namespace
labels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: v1.25
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/audit-version: v1.25
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: v1.25
# 標簽有以下兩種格式：
# pod-security.kubernetes.io/<MODE>: <LEVEL>
# pod-security.kubernetes.io/<MODE>-version: <VERSION>
# audit和warn模式的作用主要在于提供相應信息供用戶排查負載違反了哪些安全行為
命名空間的標簽用來表示不同的模式所應用的安全策略級別，存在以下兩種格式：
- pod-security.kubernetes.io/:
<MODE>：隔離模式必須是enforce、audit或warn之一。
<LEVEL> ：安全性策略級別必須是privileged、baseline或restricted。
- pod-security.kubernetes.io/-version:
該標簽為可選，可以將安全性策略鎖定到Kubernetes版本號。
<MODE>：隔離模式必須是enforce、audit或warn之一。
<VERSION> ：Kubernetes版本號。例如 v1.25，也可以使用latest。
若在上述Namespace中部署Pod，則會有以下安全性限制：
- 設置了enforce隔離模式對應的策略為privileged，將會跳過enforce階段的校驗。
- 設置了audit隔離模式對應的策略為baseline，將會校驗baseline策略相關限制，即如果Pod或Container違反了該策略，審計日志中將添加相應事件。
- 設置了warn隔離模式對應的策略為restricted，將會校驗restricted策略相關限制，即如果Pod或Container違反了該策略，用戶將會在創建pod時收到告警信息。
從PodSecurityPolicy遷移到Pod Security Admission
如您在1.25之前版本的集群中使用了PodSecurityPolicy，且需要在1.25及以后版本集群中繼續使用Pod Security Admission來替代PodSecurityPolicy的用戶，請參見。
注意
由于Pod Security Admission僅支持三種隔離模式，因此靈活性相比于PodSecurityPolicy較差，部分場景下需要用戶自行定義驗證準入Webhook來實施更精準的策略
由于PodSecurityPolicy具有變更能力，而Pod Security Admission并不具備該能力，因此之前依賴該能力的用戶需要自行定義變更準入Webhook或修改Pod中的securityContext字段。
PodSecurityPolicy允許為不同的服務賬號（Service Account）綁定不同策略（Kubernetes社區不建議使用該能力）。如果您有使用該能力的訴求，在遷移至Pod Security Admission后，需要自行定義第三方Webhook。
請勿將Pod Security Admission能力應用于kube-system、kube-public和kube-node-lease等一些CCE組件部署的Namespace中，否則會導致CCE組件、插件功能異常。
