Kubernetes 生产环境运维与排障实战：从入口到供应链的检查方法

Kubernetes 生产环境运维与排障实战从入口到供应链的检查方法在一次针对线上集群的安全攻防演练中安全团队未凭任何 ClusterAdmin 权限凭据仅凭一个在普通 Pod 中被忽略的缺省 ServiceAccount Token 挂载配合配置不当的 Ingress 注解Annotations在半小时内便横向移动控制了全集群的镜像拉取密钥ImagePullSecrets甚至顺藤摸瓜提取到了生产数据库的 root 密码。许多运维人员在搭建 Kubernetes 集群时习惯将注意力集中在防火墙、 Node 节点 SSH 端口与 API Server 的外网暴露控制上。然而真正导致生产集群被横向突破的往往是那些隐藏在 RBAC 通配符、容器镜像供应链以及缺省 Token 挂载细节中的“后门入口”。保护 Kubernetes 生产环境必须严防三大核心安全入口身份凭据漏洞、RBAC 提权路径与镜像供应链陷阱。凭据自动挂载隐患ServiceAccount Token 滥用与 Automount 防线默认情况下Kubernetes 创建 Pod 时会自动将所在 Namespace 的defaultServiceAccount Token 挂载到容器内的/var/run/secrets/kubernetes.io/serviceaccount/目录。一旦该 Pod 存在任意远程代码执行RCE漏洞攻击者即可直接读取该目录下的token和ca.crt文件伪装成合法 ServiceAccount 向 API Server 发起探索。彻底封堵这一入口的根本方法是在所有无需直接调用 API Server 的应用 Pod 规范中显式将automountServiceAccountToken设为falseapiVersion: apps/v1 kind: Deployment metadata: name: payment-api namespace: production spec: replicas: 3 template: metadata: labels: app: payment-api spec: # 核心防御点严禁自动挂载 ServiceAccount Token 凭据 automountServiceAccountToken: false containers: - name: app image: registry.internal.net/finance/payment-api:v1.4.2 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 10001 capabilities: drop: - ALLRBAC 提权路径审计从 Wildcard 到 API 代理越权的诊断命令RBAC基于角色的访问控制配置滥用是 Kubernetes 安全事故的另一重灾区。开发人员为了省事常在自定义 ClusterRole 中写下verbs: [*]或resources: [*]。最危险的提权路径之一是对pods/exec或secrets具有create/get权限或者拥有nodes/proxy权限。拥有nodes/proxy权限的攻击者可以绕过 API Server 的鉴权机制直接向 Kubelet 的 10250 端口发送 command execution 请求。运维工程师必须定期使用以下专业诊断命令对集群 RBAC 权限进行“体检”与扫描# 1. 查询集群中哪些 Subject 拥有获取全局 Secret 的危险权限 kubectl get clusterrolebindings,rolebindings -A -o json | \ jq -r .items[] | select(.roleRef.name | contains(admin) or contains(secret)) | \(.metadata.namespace)/\(.metadata.name) # 2. 检查哪些 User/SA 可以使用 kubectl exec 侵入容器 kubectl get clusterroles -o json | jq -r .items[] | select(.rules[]? | .resources[]? pods/exec and (.verbs[]? * or .verbs[]? create)) | .metadata.name # 3. 使用 kubectl-who-can 插件诊断可访问/修改敏感配置的实体 kubectl who-can delete nodes kubectl who-can get secrets -A # 4. 实时审查默认 Namespace 下是否存在未禁用的敏感绑定 kubectl get serviceaccount default -o jsonpath{.automountServiceAccountToken}镜像供应链安全防线Cosign 签名与 Kyverno 强管制实战即便 K8s 集群本身的 RBAC 配置严丝合缝如果黑客篡改了企业私有镜像仓库中的 Docker 镜像在代码中植入了恶意后门应用一旦部署依然会导致安全失守。解决供应链风险的关键是建立镜像签名验证 (Cosign)与准入控制器 (Admission Controller)的联动拦截机制。只允许包含公钥签名的可信镜像部署到集群中。使用 Kyverno 准入控制器强制校验镜像签名的策略配置如下apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: verify-image-cosign-signature annotations: policies.kyverno.io/title: Verify Image Cosign Signature policies.kyverno.io/subject: Pod spec: validationFailureAction: Enforce background: false rules: - name: verify-signature match: any: - resources: kinds: - Pod namespaces: - production verifyImages: - imageReferences: - registry.internal.net/finance/* key: | -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7L1J... (公司企业级 Cosign 验签公钥) -----END PUBLIC KEY----- attestations: - predicateType: https://cosign.sigstore.dev/attestation/v1在 CI 流水线构建镜像时使用 Sigstore Cosign 命令对镜像进行确定性签名与发布# 1. 使用 Cosign 对构建完成的容器镜像进行私钥签名 cosign sign --key k8s-prod-cosign.key registry.internal.net/finance/payment-api:v1.4.2 # 2. 手动验签测试确认镜像签名有效性 cosign verify --key k8s-prod-cosign.pub registry.internal.net/finance/payment-api:v1.4.2 # 3. 在集群内部审计未签名镜像部署拦截日志 kubectl get events -n production --field-selector reasonPolicyViolation堵住 ServiceAccount Token 的默认挂载漏口清除 RBAC 权限中的通配符与代理提权隐患并在准入控制关卡上紧 Cosign 镜像签名校验锁。这三道防线结合在一起才能打造出坚不可摧的 Kubernetes 生产安全体系。