当前位置：首页 > news >正文

云原生技术25-云原生安全：从零信任到容器运行时防护，Kubernetes安全加固：20个必须知道的安全配置

news 2026/7/1 12:08:50

1、AI程序员系列文章
2、AI面试系列文章
3、AI编程系列文章

开篇：你的K8s集群安全吗？

你是否担心容器逃逸、镜像漏洞、权限过大的安全风险？

想象一下：你把所有家当都放在一个智能保险箱里，结果发现保险箱的密码是"123456"，而且门还留了一条缝——这就是很多K8s集群的真实写照。

云原生安全需要覆盖镜像、运行时、网络、密钥等多个层面。本文将给出全面的K8s安全加固方案，帮你把"家当"真正锁好。

💡效率技巧：安全不是一次性工作，而是持续的过程。建议每季度进行一次安全审计。

镜像安全：从源头堵住漏洞

1.1 镜像扫描：给你的镜像做个"体检"

就像去医院体检一样，镜像也需要定期检查。Trivy和Grype是目前最流行的两款扫描工具。

Trivy 扫描示例：

# 安装 Trivy # macOS brew install aquasecurity/trivy/trivy # Linux curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin # 扫描镜像 trivy image nginx:latest # 只显示高危漏洞 trivy image --severity HIGH,CRITICAL nginx:latest # 输出为JSON格式 trivy image --format json -o report.json nginx:latest

Grype 扫描示例：

# 安装 Grype curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin # 扫描镜像 grype nginx:latest # 忽略已修复的漏洞 grype --only-fixed nginx:latest

⚠️避坑警告：不要只扫描一次就完事！建议在CI/CD流水线中集成镜像扫描，每次构建都自动检查。

1.2 最小镜像：Less is More

想象一下，你请了一个保镖，结果他自带了全套露营装备——帐篷、烧烤架、甚至KTV设备。这保镖能保护你吗？能。但攻击面也大了。

传统镜像 vs 最小镜像：

┌─────────────────────────────────────────────────────────┐ │ 传统镜像 (Ubuntu) │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ shell │ │ apt │ │ vim │ │ curl │ │ │ │ bash │ │ dpkg │ │ nano │ │ wget │ │ │ │ ssh │ │ gcc │ │ git │ │ python │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │ 攻击面：███████████████████████████████████████ 100% │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ 最小镜像 (Distroless) │ │ ┌─────────┐ │ │ │ App │ ← 只有你的应用和运行时依赖 │ │ └─────────┘ │ │ 攻击面：███ 15% │ └─────────────────────────────────────────────────────────┘

Dockerfile 最佳实践：

# ❌ 错误示范：使用完整操作系统 FROM ubuntu:22.04 RUN apt-get update && apt-get install -y python3 COPY app.py /app/ CMD ["python3", "/app/app.py"] # ✅ 正确示范：多阶段构建 + 最小镜像 # 阶段1：构建 FROM python:3.11-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --user --no-cache-dir -r requirements.txt # 阶段2：运行（使用 distroless 或 alpine） FROM gcr.io/distroless/python3-debian11 COPY --from=builder /root/.local /home/nonroot/.local COPY app.py /app/ ENV PATH=/home/nonroot/.local/bin:$PATH USER nonroot CMD ["/app/app.py"]

常用最小镜像选择：

镜像类型	推荐基础镜像	适用场景
Go	`scratch`,`distroless/static`	静态编译，零依赖
Java	`distroless/java`,`eclipse-temurin:jre-alpine`	JRE运行时
Node.js	`node:alpine`,`distroless/nodejs`	轻量级运行时
Python	`python:alpine`,`distroless/python3`	精简Python环境

1.3 无root运行：别给攻击者"管理员权限"

💡效率技巧：使用非root用户运行容器，可以将容器逃逸的影响降到最低。

# ❌ 错误：以root运行 FROM nginx:latest COPY nginx.conf /etc/nginx/nginx.conf # ✅ 正确：创建非root用户 FROM nginx:alpine # 创建非root用户 RUN addgroup -g 1000 appgroup && \ adduser -u 1000 -G appgroup -s /bin/sh -D appuser # 修改文件权限 COPY --chown=appuser:appgroup nginx.conf /etc/nginx/nginx.conf COPY --chown=appuser:appgroup html /usr/share/nginx/html # 切换到非root用户 USER appuser EXPOSE 8080

Kubernetes Pod 安全配置：

apiVersion: v1 kind: Pod metadata: name: secure-pod spec: securityContext: runAsNonRoot: true # 禁止root运行 runAsUser: 1000 # 指定用户ID runAsGroup: 1000 # 指定组ID fsGroup: 1000 # 卷挂载的组权限 containers: - name: app image: myapp:v1.0 securityContext: allowPrivilegeEscalation: false # 禁止权限提升 readOnlyRootFilesystem: true # 根文件系统只读 capabilities: drop: - ALL # 丢弃所有特权 add: - NET_BIND_SERVICE # 只添加必要的权限

运行时安全：别让容器变成"越狱犯"

2.1 Seccomp：系统调用的"白名单"

Seccomp（Secure Computing Mode）就像是给容器发了一张"权限清单"，只允许做清单上的事情。

┌─────────────────────────────────────────────────────────────┐ │ Seccomp 工作示意 │ │ │ │ 容器应用 ──► Seccomp过滤器 ──► 允许? ──► 系统调用 │ │ │ │ │ ▼ │ │ ┌──────────┐ │ │ │ 白名单 │ │ │ │ • read │ │ │ │ • write │ │ │ │ • exit │ │ │ │ • ... │ │ │ └──────────┘ │ │ │ │ │ ▼ │ │ 不在白名单? ──► 拒绝并记录 │ └─────────────────────────────────────────────────────────────┘

Kubernetes 启用 Seccomp：

apiVersion: v1 kind: Pod metadata: name: seccomp-pod annotations: # 使用RuntimeDefault配置（推荐） seccomp.security.alpha.kubernetes.io/pod: "runtime/default" spec: containers: - name: app image: nginx:alpine securityContext: seccompProfile: type: RuntimeDefault

自定义 Seccomp 配置文件：

{ "defaultAction": "SCMP_ACT_ERRNO", "architectures": ["SCMP_ARCH_X86_64"], "syscalls": [ { "names": [ "accept", "accept4", "bind", "clone", "close", "connect", "exit", "exit_group", "fcntl", "fstat", "futex", "getpid", "getrandom", "ioctl", "mmap", "munmap", "open", "openat", "poll", "read", "recvfrom", "recvmsg", "sendmsg", "sendto", "socket", "write" ], "action": "SCMP_ACT_ALLOW" } ] }

2.2 AppArmor：MAC（强制访问控制）

AppArmor就像是给程序穿了一件"防护服"，规定它能访问哪些文件、能做什么操作。

⚠️避坑警告：AppArmor主要在Ubuntu/Debian系列发行版上可用，CentOS/RHEL请使用SELinux。

AppArmor 配置文件示例：

#include <tunables/global> profile k8s-app flags=(attach_disconnected,mediate_deleted) { #include <abstractions/base> # 允许网络访问 network inet stream, network inet6 stream, # 允许读取应用文件 /app/** r, # 允许写入临时目录 /tmp/** rw, /var/tmp/** rw, # 允许日志写入 /var/log/myapp/** rw, # 禁止访问敏感文件 deny /etc/shadow r, deny /etc/passwd w, deny /proc/sys/** w, deny /sys/** w, # 允许标准库 /lib/** mr, /lib64/** mr, /usr/lib/** mr, }

Kubernetes 使用 AppArmor：

apiVersion: v1 kind: Pod metadata: name: apparmor-pod annotations: # 指定AppArmor配置文件 container.apparmor.security.beta.kubernetes.io/app: localhost/k8s-app spec: containers: - name: app image: myapp:v1.0

2.3 SELinux：更细粒度的访问控制

SELinux就像是给系统资源贴上了"标签"，只有标签匹配的程序才能访问对应的资源。

┌─────────────────────────────────────────────────────────────┐ │ SELinux 标签示意 │ │ │ │ 进程标签: system_u:system_r:container_t:s0:c123,c456 │ │ │ │ │ ▼ │ │ 文件标签: system_u:object_r:container_file_t:s0:c123,c456 │ │ │ │ │ ▼ │ │ 标签匹配? ──► 允许访问 │ └─────────────────────────────────────────────────────────────┘

Kubernetes 启用 SELinux：

apiVersion: v1 kind: Pod metadata: name: selinux-pod spec: securityContext: seLinuxOptions: level: "s0:c123,c456" # 指定SELinux级别 role: "system_r" type: "container_t" user: "system_u" containers: - name: app image: myapp:v1.0 securityContext: seLinuxOptions: level: "s0:c123,c456"

2.4 gVisor & Kata Containers：更强的隔离

如果说普通容器是"合租公寓"，那gVisor和Kata就是"独栋别墅"。

┌─────────────────────────────────────────────────────────────────────┐ │ 容器隔离级别对比 │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ runc │ │ gVisor │ │ Kata │ │ VM │ │ │ │ (默认) │ │ (用户态) │ │ (轻量VM) │ │ (传统) │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ │ 隔离性: ★★☆ 隔离性: ★★★☆ 隔离性: ★★★★ 隔离性: ★★★★★ │ │ 性能: ★★★★★ 性能: ★★★★ 性能: ★★★☆ 性能: ★★☆ │ │ 兼容性:★★★★★ 兼容性: ★★★☆ 兼容性: ★★★★ 兼容性: ★★★ │ └─────────────────────────────────────────────────────────────────────┘

使用 gVisor：

# 安装 gVisor ( set -e ARCH=$(uname -m) URL=https://storage.googleapis.com/gvisor/releases/release/latest wget ${URL}/${ARCH}/runsc ${URL}/${ARCH}/runsc.sha512 sha512sum -c runsc.sha512 chmod a+rx runsc sudo mv runsc /usr/local/bin ) # 配置 containerd 使用 gVisor sudo mkdir -p /etc/containerd sudo containerd config default | sudo tee /etc/containerd/config.toml # 添加 runtime 配置 cat <<EOF | sudo tee -a /etc/containerd/config.toml [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc] runtime_type = "io.containerd.runsc.v1" EOF sudo systemctl restart containerd

Kubernetes RuntimeClass 使用 gVisor：

# 创建 RuntimeClass apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc --- # 使用 gVisor 运行 Pod apiVersion: v1 kind: Pod metadata: name: gvisor-pod spec: runtimeClassName: gvisor containers: - name: app image: nginx:alpine

使用 Kata Containers：

apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: kata handler: kata --- apiVersion: v1 kind: Pod metadata: name: kata-pod spec: runtimeClassName: kata containers: - name: app image: nginx:alpine

💡效率技巧：gVisor适合对安全性要求高但性能要求不极端的场景；Kata适合需要接近VM隔离级别的场景。

网络安全：构建零信任防线

3.1 NetworkPolicy：K8s的"防火墙"

想象一下，你的K8s集群是一个大型商场，NetworkPolicy就是商场的"门禁系统"——规定谁可以进哪个店铺。

┌─────────────────────────────────────────────────────────────────┐ │ NetworkPolicy 架构示意 │ │ │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │ │ Frontend │◄────►│ Backend │◄────►│ Database │ │ │ │ (Web) │ │ (API) │ │ (MySQL) │ │ │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ │ │ │ │ 只允许80/443 │ 只允许8080 │ 只允许3306 │ │ │ │ │ │ │ ┌─────▼──────────────────▼──────────────────▼─────┐ │ │ │ 默认拒绝所有流量 │ │ │ │ (除非明确允许，否则拒绝) │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘

默认拒绝所有入站流量：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: production spec: podSelector: {} # 选择所有Pod policyTypes: - Ingress # 拒绝所有入站流量

允许特定流量：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-allow namespace: production spec: podSelector: matchLabels: app: api policyTypes: - Ingress ingress: # 允许 frontend 访问 - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080 # 允许监控采集指标 - from: - namespaceSelector: matchLabels: name: monitoring ports: - protocol: TCP port: 9090

数据库访问控制：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-allow namespace: production spec: podSelector: matchLabels: app: database policyTypes: - Ingress ingress: # 只允许 api 服务访问数据库 - from: - podSelector: matchLabels: app: api ports: - protocol: TCP port: 3306

3.2 服务网格 mTLS：服务间的"加密通话"

就像特工之间的通话需要加密一样，服务之间的通信也需要加密。Istio和Linkerd可以帮你自动实现这一点。

┌─────────────────────────────────────────────────────────────────┐ │ mTLS 加密通信示意 │ │ │ │ ┌───────────┐ ┌───────────┐ │ │ │ Service A │◄───── 加密通道 ────►│ Service B │ │ │ │ │ ╔═══════════╗ │ │ │ │ │ ┌─────┐ │ ║ mTLS ║ │ ┌─────┐ │ │ │ │ │证书A│──┼────►双向认证 ◄───┼──│证书B│ │ │ │ │ └─────┘ │ ║ 加密传输 ║ │ └─────┘ │ │ │ │ │ ╚═══════════╝ │ │ │ │ └───────────┘ └───────────┘ │ │ │ │ 特点： │ │ ✓ 自动证书管理（颁发、轮换、吊销） │ │ ✓ 服务身份认证（基于SPIFFE身份） │ │ ✓ 传输加密（防止中间人攻击） │ └─────────────────────────────────────────────────────────────────┘

Istio PeerAuthentication 启用 mTLS：

# 全局启用严格 mTLS apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT --- # 特定命名空间启用 mTLS apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: production spec: mtls: mode: STRICT

Istio AuthorizationPolicy 细粒度访问控制：

apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: api-policy namespace: production spec: selector: matchLabels: app: api action: ALLOW rules: # 只允许 frontend 服务访问 /api/* 路径 - from: - source: principals: ["cluster.local/ns/production/sa/frontend"] to: - operation: paths: ["/api/*"] methods: ["GET", "POST"] # 允许监控服务访问 /metrics - from: - source: namespaces: ["monitoring"] to: - operation: paths: ["/metrics"] methods: ["GET"]

3.3 零信任网络：“永不信任，始终验证”

零信任的核心思想：即使是内部网络，也要像面对公网一样谨慎。

零信任架构原则：

┌─────────────────────────────────────────────────────────────────┐ │ 零信任安全模型 │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 身份验证层 │ │ │ │ (Who) 你是谁？ ──► 多因素认证、设备证书、用户身份 │ │ │ └─────────────────────────┬───────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 设备健康检查 │ │ │ │ (What) 你的设备安全吗？ ──► 补丁状态、安全软件、合规性 │ │ │ └─────────────────────────┬───────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 最小权限访问 │ │ │ │ (Access) 你能访问什么？ ──► 按需授权、动态策略、审计 │ │ │ └─────────────────────────┬───────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 持续监控验证 │ │ │ │ (Monitor) 持续验证 ──► 行为分析、异常检测、实时响应 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ 核心原则：永不信任，始终验证 │ └─────────────────────────────────────────────────────────────────┘

密钥管理： secrets不是"公开的秘密"

4.1 Kubernetes Secrets 加密

默认情况下，K8s Secrets是以base64编码存储在etcd中的——这就像把密码写在纸条上，然后放进透明塑料袋。

⚠️避坑警告：base64不是加密！任何能看到etcd数据的人都能看到你的secrets。

启用 etcd 加密：

# /etc/kubernetes/manifests/kube-apiserver.yaml apiVersion: v1 kind: Pod metadata: name: kube-apiserver spec: containers: - name: kube-apiserver command: - kube-apiserver - --encryption-provider-config=/etc/kubernetes/encryption-config.yaml # ... 其他参数 volumeMounts: - name: encryption-config mountPath: /etc/kubernetes/encryption-config.yaml readOnly: true volumes: - name: encryption-config hostPath: path: /etc/kubernetes/encryption-config.yaml

加密配置文件：

# /etc/kubernetes/encryption-config.yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets - configmaps providers: # 使用 KMS 插件（推荐） - kms: name: myKMSPlugin endpoint: unix:///var/run/k8s-kms-plugin/socket.sock cachesize: 1000 timeout: 3s # 或使用 AES-GCM - aescbc: keys: - name: key1 secret: <base64-encoded-32-byte-key> # 或使用 AES-GCM - aesgcm: keys: - name: key1 secret: <base64-encoded-32-byte-key> # 最后保留 identity，用于解密未加密的数据 - identity: {}

4.2 HashiCorp Vault 集成

Vault就像是企业的"密码保险箱"，提供动态密钥、自动轮换、访问审计等功能。

Vault Kubernetes 认证：

# 启用 Kubernetes 认证 vault auth enable kubernetes # 配置 Kubernetes 认证 vault write auth/kubernetes/config \ token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt # 创建策略 vault policy write myapp - <<EOF path "secret/data/myapp/*" { capabilities = ["read"] } EOF # 创建角色 vault write auth/kubernetes/role/myapp \ bound_service_account_names=myapp-sa \ bound_service_account_namespaces=production \ policies=myapp \ ttl=1h

使用 Vault Agent Sidecar 注入 Secrets：

apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: annotations: # Vault Agent 注入配置 vault.hashicorp.com/agent-inject: "true" vault.hashicorp.com/role: "myapp" vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/myapp" vault.hashicorp.com/agent-inject-template-db-creds: | {{ with secret "database/creds/myapp" -}} export DB_USERNAME="{{ .Data.username }}" export DB_PASSWORD="{{ .Data.password }}" {{- end }} vault.hashicorp.com/agent-run-as-user: "1000" spec: serviceAccountName: myapp-sa containers: - name: myapp image: myapp:v1.0 command: ["/bin/sh", "-c"] args: - source /vault/secrets/db-creds && ./start-app

4.3 证书自动轮换

证书过期就像是身份证过期——不是不能用，但会很麻烦。cert-manager可以帮你自动管理证书。

安装 cert-manager：

# 安装 cert-manager kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml # 验证安装 kubectl wait --for=condition=ready pod -l app=cert-manager -n cert-manager

创建 ClusterIssuer（Let’s Encrypt）：

apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: admin@example.com privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: nginx

自动申请证书：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myapp annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: tls: - hosts: - myapp.example.com secretName: myapp-tls rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: myapp port: number: 80

审计合规：让安全有据可查

5.1 RBAC 审计

RBAC（基于角色的访问控制）就像是公司的门禁系统——谁可以进哪个房间，一目了然。

查看当前 RBAC 配置：

# 查看所有角色 kubectl get roles,clusterroles --all-namespaces # 查看角色绑定 kubectl get rolebindings,clusterrolebindings --all-namespaces # 查看特定用户的权限 kubectl auth can-i --list --as=system:serviceaccount:production:myapp-sa # 检查用户是否有特定权限 kubectl auth can-i create pods --as=system:serviceaccount:production:myapp-sa

最小权限 RBAC 示例：

# 创建 ServiceAccount apiVersion: v1 kind: ServiceAccount metadata: name: myapp-sa namespace: production --- # 创建最小权限 Role apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: myapp-role namespace: production rules: # 只允许读取 ConfigMap - apiGroups: [""] resources: ["configmaps"] verbs: ["get", "list", "watch"] resourceNames: ["myapp-config"] # 只允许读取 Secrets（特定名称） - apiGroups: [""] resources: ["secrets"] verbs: ["get"] resourceNames: ["myapp-secret"] --- # 绑定 Role apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: myapp-binding namespace: production subjects: - kind: ServiceAccount name: myapp-sa namespace: production roleRef: kind: Role name: myapp-role apiGroup: rbac.authorization.k8s.io

5.2 Pod 安全标准

Kubernetes 1.23+ 引入了 Pod Security Standards，提供了三个级别的安全策略。

┌─────────────────────────────────────────────────────────────────┐ │ Pod 安全标准级别 │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Privileged │ │ Baseline │ │ Restricted │ │ │ │ (特权) │ │ (基线) │ │ (受限) │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ 无限制，允许所有 禁止已知风险配置 最佳实践，最严格 │ │ │ │ │ │ │ 适用：开发/测试 适用：生产环境 适用：高安全场景 │ │ │ │ 推荐：生产环境至少使用 Baseline，敏感业务使用 Restricted │ └─────────────────────────────────────────────────────────────────┘

启用 Pod Security Admission：

# 命名空间级别配置 apiVersion: v1 kind: Namespace metadata: name: production labels: # 强制执行 Restricted 标准 pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/enforce-version: latest # 审计模式记录 Baseline 违规 pod-security.kubernetes.io/audit: baseline pod-security.kubernetes.io/audit-version: latest # 警告模式提示 Privileged 违规 pod-security.kubernetes.io/warn: privileged pod-security.kubernetes.io/warn-version: latest

5.3 CIS 基准检查

CIS（Center for Internet Security）基准就像是云原生安全的"体检报告"。

使用 kube-bench 进行检查：

# 安装 kube-bench curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.17/kube-bench_0.6.17_linux_amd64.tar.gz | tar -xz sudo mv kube-bench /usr/local/bin/ # 运行检查 kube-bench run # 只检查 master 节点 kube-bench run --targets master # 只检查 node 节点 kube-bench run --targets node # 输出为 JSON kube-bench run --json # 自动修复（谨慎使用！） kube-bench run -- remediate

CIS 关键检查项：

检查项	描述	风险等级
1.2.6	确保 --kubelet-certificate-authority 已设置	高
1.2.16	确保 --audit-log-path 已设置	高
1.2.17	确保 --audit-log-maxage 已设置	中
1.2.18	确保 --audit-log-maxbackup 已设置	中
1.2.19	确保 --audit-log-maxsize 已设置	中
4.2.1	确保 --protect-kernel-defaults 已设置	高
4.2.6	确保 --make-iptables-util-chains 已设置	高
5.1.5	确保 default service accounts 未被主动使用	中
5.2.2	确保 SELinux 已启用	中
5.2.3	确保 --client-ca-file 参数已设置	高

实战案例：完整安全配置清单

完整安全配置模板

apiVersion: v1 kind: Namespace metadata: name: secure-app labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restricted --- apiVersion: v1 kind: ServiceAccount metadata: name: secure-app-sa namespace: secure-app automountServiceAccountToken: false # 禁止自动挂载 token --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secure-app-role namespace: secure-app rules: - apiGroups: [""] resources: ["configmaps"] verbs: ["get", "list"] resourceNames: ["app-config"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: secure-app-binding namespace: secure-app subjects: - kind: ServiceAccount name: secure-app-sa namespace: secure-app roleRef: kind: Role name: secure-app-role apiGroup: rbac.authorization.k8s.io --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: secure-app spec: podSelector: {} policyTypes: - Ingress - Egress --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-app-ingress namespace: secure-app spec: podSelector: matchLabels: app: secure-app policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: ingress-nginx ports: - protocol: TCP port: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: secure-app namespace: secure-app spec: replicas: 3 selector: matchLabels: app: secure-app template: metadata: labels: app: secure-app spec: serviceAccountName: secure-app-sa automountServiceAccountToken: false securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 1000 fsGroup: 1000 seccompProfile: type: RuntimeDefault containers: - name: app image: myregistry/secure-app:v1.0.0 imagePullPolicy: Always ports: - containerPort: 8080 protocol: TCP securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL resources: requests: memory: "128Mi" cpu: "100m" limits: memory: "256Mi" cpu: "200m" volumeMounts: - name: tmp mountPath: /tmp - name: cache mountPath: /cache volumes: - name: tmp emptyDir: {} - name: cache emptyDir: sizeLimit: 100Mi

文末三件套

1. 【源码获取】

关注此系列获取后续更新，后台回复‘security’获取完整代码示例和配置文件。

2. 【思考题】

你的K8s集群通过CIS基准检查了吗？

[ ] 已运行 kube-bench 检查
[ ] 高危项已全部修复
[ ] 建立了定期扫描机制
[ ] 团队已接受安全培训

如果还有未勾选的项，建议尽快补齐——安全无小事！

3. 【系列预告】

云原生系列文章持续更新中：

已发布： ├── 01-云原生入门指南 ├── 02-Docker基础与实践 ├── ... └── 25-云原生安全最佳实践 ← 本文 即将发布： ├── 26-性能调优：榨干K8s每一滴性能 ├── 27-监控告警：让问题无处遁形 ├── 28-故障排查：K8s问题诊断手册 └── 29-系列总结：云原生架构全景图

总结

云原生安全不是一道选择题，而是一道必答题。

通过本文，我们学习了：

安全层面	关键措施	预期效果
镜像安全	镜像扫描 + 最小镜像 + 无root	漏洞减少 80%+
运行时安全	Seccomp + AppArmor/SELinux + gVisor	容器逃逸风险大幅降低
网络安全	NetworkPolicy + mTLS + 零信任	东西向流量安全
密钥管理	etcd加密 + Vault + 证书轮换	secrets泄露风险归零
审计合规	RBAC审计 + Pod安全标准 + CIS	合规通过率 95%+