在使用Pod Security Admission前，需要先了解Kubernetes的Pod安全性标准（Security Standards）。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 Standards）。
关于如何在Pod或容器中设置Security Context，请参见为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的用户，请参见从PodSecurityPolicy迁移到内置的Pod Security Admission。
注意
由于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组件、插件功能异常。
