implementing-pod-security-admission-controller
使用内置准入控制器在命名空间级别实施 Kubernetes Pod Security Admission(Pod 安全准入),强制执行基线和受限安全配置文件。
Best use case
implementing-pod-security-admission-controller is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
使用内置准入控制器在命名空间级别实施 Kubernetes Pod Security Admission(Pod 安全准入),强制执行基线和受限安全配置文件。
Teams using implementing-pod-security-admission-controller should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/implementing-pod-security-admission-controller/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How implementing-pod-security-admission-controller Compares
| Feature / Agent | implementing-pod-security-admission-controller | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
使用内置准入控制器在命名空间级别实施 Kubernetes Pod Security Admission(Pod 安全准入),强制执行基线和受限安全配置文件。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 实施 Pod Security Admission 控制器
## 概述
Pod Security Admission(PSA,Pod 安全准入)是 Kubernetes 内置的准入控制器(v1.25 起稳定版),在命名空间级别强制执行 Pod 安全标准(Pod Security Standards)。它替代了已弃用的 PodSecurityPolicy(PSP),提供三种安全配置文件:Privileged(特权)、Baseline(基线)和 Restricted(受限),以及三种强制模式:enforce(强制)、audit(审计)和 warn(警告)。
## 前置条件
- Kubernetes v1.25+(PSA 为稳定/GA 版)
- 具有 cluster-admin 权限的 kubectl
- 无需依赖外部工具 - PSA 内置于 kube-apiserver
## Pod 安全标准
### Privileged(特权)配置文件
- **无限制** - 不施加任何限制
- 用例:系统级 Pod(kube-system、监控)
### Baseline(基线)配置文件
- **最低限制** - 防止已知权限提升
- 阻止:特权容器、hostPID、hostIPC、hostNetwork、hostPorts、某些卷类型、超出运行时默认值的能力添加
### Restricted(受限)配置文件
- **严格限制** - 遵循安全最佳实践
- 要求:非 root 运行、放弃所有能力、seccomp RuntimeDefault、考虑只读根文件系统
- 阻止:基线配置文件中的一切,加上 root 运行、权限提升、非批准的卷类型
## 强制模式
| 模式 | 行为 | 用例 |
|------|----------|----------|
| enforce | 拒绝违反策略的 Pod | 生产强制执行 |
| audit | 将违规记录到审计日志 | 强制执行前评估 |
| warn | 向用户显示警告 | 开发者反馈 |
## 实施
### 通过 Label 应用到命名空间
```yaml
# 受限强制执行,同时启用审计和警告
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: v1.28
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: v1.28
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: v1.28
```
```yaml
# staging 使用基线强制执行
apiVersion: v1
kind: Namespace
metadata:
name: staging
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: v1.28
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: v1.28
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: v1.28
```
```yaml
# 系统命名空间使用特权模式
apiVersion: v1
kind: Namespace
metadata:
name: kube-system
labels:
pod-security.kubernetes.io/enforce: privileged
```
### 使用 kubectl 应用 Label
```bash
# 设置受限强制执行
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=v1.28 \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted
# 设置基线强制执行
kubectl label namespace staging \
pod-security.kubernetes.io/enforce=baseline \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted
# 检查当前 label
kubectl get namespace production -o jsonpath='{.metadata.labels}' | jq .
```
## 演练测试
```bash
# 测试在命名空间上应用受限策略的效果
kubectl label --dry-run=server --overwrite namespace staging \
pod-security.kubernetes.io/enforce=restricted
# 输出显示已有哪些 Pod 会违反该策略
# 警告:命名空间 "staging" 中的现有 Pod 违反了新的 PodSecurity enforce 级别 "restricted:latest"
```
## 集群范围默认值(AdmissionConfiguration)
```yaml
# /etc/kubernetes/psa-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
enforce: baseline
enforce-version: latest
audit: restricted
audit-version: latest
warn: restricted
warn-version: latest
exemptions:
usernames: []
runtimeClasses: []
namespaces:
- kube-system
- kube-public
- kube-node-lease
- calico-system
- gatekeeper-system
- monitoring
- falco
```
### 应用到 API Server
```bash
# 添加到 kube-apiserver 清单
# /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
- --admission-control-config-file=/etc/kubernetes/psa-config.yaml
volumeMounts:
- name: psa-config
mountPath: /etc/kubernetes/psa-config.yaml
readOnly: true
volumes:
- name: psa-config
hostPath:
path: /etc/kubernetes/psa-config.yaml
type: File
```
## 合规 Pod 示例
### 符合 Restricted 要求的 Pod
```yaml
apiVersion: v1
kind: Pod
metadata:
name: restricted-pod
namespace: production
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
automountServiceAccountToken: false
containers:
- name: app
image: myregistry/myapp:v1.0.0
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
resources:
limits:
cpu: 500m
memory: 256Mi
requests:
cpu: 100m
memory: 128Mi
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
```
### 符合 Baseline 要求的 Pod
```yaml
apiVersion: v1
kind: Pod
metadata:
name: baseline-pod
namespace: staging
spec:
containers:
- name: app
image: myregistry/myapp:v1.0.0
securityContext:
allowPrivilegeEscalation: false
resources:
limits:
cpu: 500m
memory: 256Mi
```
## 从 PodSecurityPolicy 迁移
### 步骤 1:审计当前状态
```bash
# 检查现有 PSP
kubectl get psp
# 检查哪些 ServiceAccount 使用了哪个 PSP
kubectl get clusterrolebinding -o json | \
jq '.items[] | select(.roleRef.name | startswith("psp-")) | {name: .metadata.name, subjects: .subjects}'
```
### 步骤 2:将 PSP 映射到 PSA 配置文件
```bash
# 对每个命名空间确定所需的 PSA 级别
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
echo "命名空间:$ns"
kubectl label --dry-run=server namespace $ns \
pod-security.kubernetes.io/enforce=restricted 2>&1 | head -5
done
```
### 步骤 3:应用 PSA Label(先审计)
```bash
# 从审计模式开始
kubectl label namespace production \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted
```
### 步骤 4:审查并修复违规
```bash
# 检查审计日志中的违规
kubectl get events --field-selector reason=FailedCreate -A
```
### 步骤 5:启用强制执行
```bash
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted
```
## 监控
```bash
# 检查事件中的 PSA 违规
kubectl get events --all-namespaces --field-selector reason=FailedCreate
# 检查审计日志
kubectl logs -n kube-system kube-apiserver-* | grep "pod-security.kubernetes.io"
# 列出命名空间的 PSA label
kubectl get namespaces -L pod-security.kubernetes.io/enforce
```
## 最佳实践
1. **先用审计+警告**,在强制执行前评估影响
2. **使用演练测试**,应用前测试强制执行效果
3. **豁免系统命名空间**(kube-system、监控),在集群默认值中排除
4. **固定版本**(enforce-version),确保跨升级的可预测行为
5. **将集群范围基线设为默认值**,然后针对特定命名空间收紧
6. **与 Gatekeeper 结合**,实现 PSA 之外的额外自定义策略
7. **所有生产工作负载使用受限配置文件**
8. **记录豁免并附清晰理由**Related Skills
triaging-security-incident
使用 NIST SP 800-61r3 和 SANS PICERL 框架对安全事件进行初始分类,确定严重性、范围和所需响应行动。 按类型对事件分类,根据业务影响分配优先级,并路由到相应的响应团队。适用于事件分类、 安全告警分类、严重性评估、事件优先级排序或初始事件分析等请求场景。
triaging-security-incident-with-ir-playbook
使用结构化 IR Playbook 对安全事件进行分类和优先排序,确定严重性、分配响应团队并启动适当的响应程序。
triaging-security-alerts-in-splunk
在 Splunk Enterprise Security 中对安全告警进行分类,通过 SPL 查询和事件审查(Incident Review) 仪表板对重要事件进行严重性分类、调查、关联相关遥测并做出升级或关闭决策。 适用于 SOC 分析师需要处理关联搜索产生的告警队列、确定调查优先级, 或需要为交接给二/三级分析师记录分类决策时。
testing-websocket-api-security
测试 WebSocket API 实现中的安全漏洞,包括 WebSocket 升级时缺少身份认证、跨站 WebSocket 劫持(Cross-Site WebSocket Hijacking,CSWSH)、通过 WebSocket 消息进行的注入攻击、输入校验不足、通过消息泛洪实施拒绝服务,以及通过 WebSocket 帧造成的信息泄露。测试人员使用 Burp Suite 拦截 WebSocket 握手和消息,构造恶意 payload,并测试 WebSocket 通道上的授权绕过。适用于 WebSocket 安全测试、WS 渗透测试、CSWSH 攻击或实时 API 安全评估相关请求。
testing-jwt-token-security
在安全测试活动中,评估 JSON Web Token(JWT)实现中的密码学弱点、算法混淆攻击和授权绕过漏洞。
testing-api-security-with-owasp-top-10
使用自动化和手工测试技术,针对 OWASP API 安全 Top 10 风险对 REST 和 GraphQL API 端点进行系统性评估。
performing-wireless-security-assessment-with-kismet
使用 Kismet 通过被动射频监控进行无线网络安全评估,检测流氓接入点(Rogue AP)、隐藏 SSID、弱加密和未授权客户端。
performing-ssl-tls-security-assessment
使用 sslyze Python 库评估 SSL/TLS 服务器配置,评估加密套件、证书链、协议版本、HSTS 头部,以及 Heartbleed 和 ROBOT 等已知漏洞。
performing-soap-web-service-security-testing
通过分析 WSDL 定义,测试 XML 注入(XML Injection)、XXE、WS-Security 绕过和 SOAPAction 欺骗,对 SOAP Web 服务执行安全测试。
performing-serverless-function-security-review
对 AWS Lambda、Azure Functions 和 GCP Cloud Functions 中的无服务器函数(Serverless Function)执行安全审查,识别过度宽松的执行角色(Execution Role)、不安全的环境变量、注入漏洞和缺失的运行时保护措施。
performing-scada-hmi-security-assessment
对 SCADA 人机界面(HMI, Human-Machine Interface)系统进行安全评估,识别基于 Web 的 HMI、瘦客户端配置、认证机制以及 HMI 与 PLC 之间通信信道中的漏洞,符合 IEC 62443 和 NIST SP 800-82 指南要求。
performing-s7comm-protocol-security-analysis
对西门子SIMATIC S7 PLC使用的S7comm和S7CommPlus协议进行安全分析,识别漏洞,包括重放攻击、完整性绕过、未授权的CPU停止命令以及针对S7-300、S7-400、S7-1200和S7-1500控制器弱点的程序下载操控。