implementing-pod-security-admission-controller

使用内置准入控制器在命名空间级别实施 Kubernetes Pod Security Admission(Pod 安全准入),强制执行基线和受限安全配置文件。

9 stars

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

$curl -o ~/.claude/skills/implementing-pod-security-admission-controller/SKILL.md --create-dirs "https://raw.githubusercontent.com/killvxk/cybersecurity-skills-zh/main/skills/implementing-pod-security-admission-controller/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/implementing-pod-security-admission-controller/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How implementing-pod-security-admission-controller Compares

Feature / Agentimplementing-pod-security-admission-controllerStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/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

9
from killvxk/cybersecurity-skills-zh

使用 NIST SP 800-61r3 和 SANS PICERL 框架对安全事件进行初始分类,确定严重性、范围和所需响应行动。 按类型对事件分类,根据业务影响分配优先级,并路由到相应的响应团队。适用于事件分类、 安全告警分类、严重性评估、事件优先级排序或初始事件分析等请求场景。

triaging-security-incident-with-ir-playbook

9
from killvxk/cybersecurity-skills-zh

使用结构化 IR Playbook 对安全事件进行分类和优先排序,确定严重性、分配响应团队并启动适当的响应程序。

triaging-security-alerts-in-splunk

9
from killvxk/cybersecurity-skills-zh

在 Splunk Enterprise Security 中对安全告警进行分类,通过 SPL 查询和事件审查(Incident Review) 仪表板对重要事件进行严重性分类、调查、关联相关遥测并做出升级或关闭决策。 适用于 SOC 分析师需要处理关联搜索产生的告警队列、确定调查优先级, 或需要为交接给二/三级分析师记录分类决策时。

testing-websocket-api-security

9
from killvxk/cybersecurity-skills-zh

测试 WebSocket API 实现中的安全漏洞,包括 WebSocket 升级时缺少身份认证、跨站 WebSocket 劫持(Cross-Site WebSocket Hijacking,CSWSH)、通过 WebSocket 消息进行的注入攻击、输入校验不足、通过消息泛洪实施拒绝服务,以及通过 WebSocket 帧造成的信息泄露。测试人员使用 Burp Suite 拦截 WebSocket 握手和消息,构造恶意 payload,并测试 WebSocket 通道上的授权绕过。适用于 WebSocket 安全测试、WS 渗透测试、CSWSH 攻击或实时 API 安全评估相关请求。

testing-jwt-token-security

9
from killvxk/cybersecurity-skills-zh

在安全测试活动中,评估 JSON Web Token(JWT)实现中的密码学弱点、算法混淆攻击和授权绕过漏洞。

testing-api-security-with-owasp-top-10

9
from killvxk/cybersecurity-skills-zh

使用自动化和手工测试技术,针对 OWASP API 安全 Top 10 风险对 REST 和 GraphQL API 端点进行系统性评估。

performing-wireless-security-assessment-with-kismet

9
from killvxk/cybersecurity-skills-zh

使用 Kismet 通过被动射频监控进行无线网络安全评估,检测流氓接入点(Rogue AP)、隐藏 SSID、弱加密和未授权客户端。

performing-ssl-tls-security-assessment

9
from killvxk/cybersecurity-skills-zh

使用 sslyze Python 库评估 SSL/TLS 服务器配置,评估加密套件、证书链、协议版本、HSTS 头部,以及 Heartbleed 和 ROBOT 等已知漏洞。

performing-soap-web-service-security-testing

9
from killvxk/cybersecurity-skills-zh

通过分析 WSDL 定义,测试 XML 注入(XML Injection)、XXE、WS-Security 绕过和 SOAPAction 欺骗,对 SOAP Web 服务执行安全测试。

performing-serverless-function-security-review

9
from killvxk/cybersecurity-skills-zh

对 AWS Lambda、Azure Functions 和 GCP Cloud Functions 中的无服务器函数(Serverless Function)执行安全审查,识别过度宽松的执行角色(Execution Role)、不安全的环境变量、注入漏洞和缺失的运行时保护措施。

performing-scada-hmi-security-assessment

9
from killvxk/cybersecurity-skills-zh

对 SCADA 人机界面(HMI, Human-Machine Interface)系统进行安全评估,识别基于 Web 的 HMI、瘦客户端配置、认证机制以及 HMI 与 PLC 之间通信信道中的漏洞,符合 IEC 62443 和 NIST SP 800-82 指南要求。

performing-s7comm-protocol-security-analysis

9
from killvxk/cybersecurity-skills-zh

对西门子SIMATIC S7 PLC使用的S7comm和S7CommPlus协议进行安全分析,识别漏洞,包括重放攻击、完整性绕过、未授权的CPU停止命令以及针对S7-300、S7-400、S7-1200和S7-1500控制器弱点的程序下载操控。