【架构实战】Kubernetes安全加固实战：从RBAC到Pod Security Standards的完整防护体系

【架构实战】Kubernetes安全加固实战从RBAC到Pod Security Standards的完整防护体系把应用跑进Kubernetes只是第一步。一旦上生产安全问题立刻浮出水面谁有权限访问集群Pod能随便跑特权容器吗容器逃逸了怎么办这篇把Kubernetes的安全体系从认证、授权、准入控制到运行时防护拆解一遍给你一套生产可用的防护方案。一、K8s安全的三层模型Kubernetes的安全模型可以抽象为三个关卡认证Authentication你是谁验证身份授权Authorization你能干什么验证权限准入控制Admission Control你提交的请求合规吗验证请求内容三层关卡串在一起每一层都能拦截非法请求。理解了这个模型安全问题就是在哪一层加强防护的选择题。二、认证谁有资格进集群Kubernetes支持多种认证方式生产环境通常组合使用2.1 客户端证书认证最常用的方式。每个用户/服务账户绑定一个客户端证书API Server通过证书CNCommon Name识别身份。kubeconfig文件里的client-certificate就是这东西。注意证书一旦签发权限就跟着证书走。吊销权限需要重新签发证书管理成本高。建议用短期证书如24小时有效期 自动续期工具如cert-manager。2.2 Service Account TokenPod访问API Server默认用ServiceAccount的JWT Token。Token挂载在/var/run/secrets/kubernetes.io/serviceaccount/token。Kubernetes会自动验证Token签名和过期时间。增强做法开启BoundServiceAccountTokenVolumeKubernetes 1.20Token会定期轮换用ServiceAccountTokenPodNodeInfo绑定Token到Pod所在节点防Token被盗用后跨节点使用。2.3 OIDC集成企业环境常用OIDC如Keycloak、Dex、Azure AD对接现有身份系统。用户登录后拿到OIDC TokenAPI Server验证Token并映射到Kubernetes用户。配置示例--oidc-issuer-urlhttps://keycloak.example.com/auth/realms/myrealm--oidc-client-idkubernetes--oidc-username-claimemail--oidc-groups-claimgroups这样就能用公司SSO登录kubectl权限按OIDC里的group自动映射。三、授权RBAC到底怎么配认证通过后进入授权阶段。Kubernetes默认用RBACRole-Based Access Control。3.1 RBAC的四要素Role/ClusterRole定义能操作哪些资源规则集合RoleBinding/ClusterRoleBinding绑定Role到User/Group/ServiceAccountRole是namespace级别ClusterRole是集群级别。绑定也分namespace级RoleBinding和集群级ClusterRoleBinding。3.2 最小权限原则新手最容易犯的错是绑定cluster-admin给普通用户。正确做法是按namespace隔离不同团队/环境用不同namespace定义精细Role只授权必要的操作如只读权限apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:name:pod-readernamespace:devrules:-apiGroups:[]resources:[pods,pods/log]verbs:[get,list,watch]用Group而非User绑定人员离职/调岗时改Group成员即可无需改RoleBinding。3.3 常用Role模板场景推荐Role开发者查看日志pod-reader自定义只读pod/logCI/CD部署应用deployer自定义可create/update deployment运维管理namespaceadmin内置namespace级完全控制集群只读审计view内置集群级只读四、准入控制请求合规性校验授权通过后请求还要过准入控制器的审查。这里可以拦截非法的Pod创建请求、注入sidecar、强制添加标签等。4.1 准入控制器的类型ValidatingAdmissionWebhook只校验不修改对象如禁止privileged容器MutatingAdmissionWebhook可以修改对象如自动注入istio-proxy容器两者配合先Mutating修改再Validating校验。4.2 生产必开的准入控制器NamespaceLifecycle防止在已删除的namespace创建资源LimitRanger限制Pod资源request/limit防止资源耗尽ResourceQuotanamespace资源配额限制PodSecurityPolicy已废弃用Pod Security Standards替代NodeRestriction限制kubelet只能修改自己节点上的Pod4.3 自定义Webhook实战比如禁止在default namespace部署应用# 准入webhook示例Python FlaskfromflaskimportFlask,request,jsonify appFlask(__name__)app.route(/validate,methods[POST])defvalidate():reqrequest.json namespacereq[request][namespace]ifnamespacedefault:returnjsonify({response:{allowed:False,status:{message:禁止在default namespace部署应用}}})returnjsonify({response:{allowed:True}})部署为ValidatingAdmissionWebhook后所有在default namespace创建Pod的请求都会被拦截。五、Pod Security Standards容器运行时防护Kubernetes 1.25废弃了PodSecurityPolicyPSP引入Pod Security StandardsPSS用namespace标签声明安全级别5.1 三个安全级别级别标签值限制强度适用场景Privilegedenforce: privileged无限制系统组件、infra PodBaselineenforce: baseline禁止明显危险配置一般应用Restrictedenforce: restricted严格限制安全敏感应用5.2 Baseline级别禁止的操作特权容器privileged: true挂载宿主机路径hostPath使用宿主机网络/IPC/PID命名空间添加危险capabilities如SYS_ADMIN5.3 Restricted级别额外要求必须以非root用户运行runAsNonRoot: true只读根文件系统readOnlyRootFilesystem: true禁止特权升级allowPrivilegeEscalation: falseSeccomp profile必填5.4 实施方式在namespace打标签kubectl label namespace myapp\pod-security.kubernetes.io/enforcerestricted\pod-security.kubernetes.io/enforce-versionlatest此后该namespace所有Pod必须符合restricted级别要求否则创建失败。六、运行时安全容器逃逸后怎么办假设攻击者已经进入容器内部如何限制其破坏范围6.1 只读根文件系统readOnlyRootFilesystem: true防止容器内被写入恶意文件。6.2 限制capabilities默认容器拥有少量capabilities如NET_BIND_SERVICE。去掉所有不必要的securityContext:capabilities:drop:[ALL]add:[NET_BIND_SERVICE]# 只保留必要能力6.3 Seccomp AppArmorSeccomp限制容器能调用的系统调用如禁止ptrace、mountAppArmor限制容器能访问的文件路径和权限Kubernetes 1.25默认启用Seccomp建议显式配置securityContext:seccompProfile:type:RuntimeDefault# 使用容器运行时默认profile6.4 网络隔离用NetworkPolicy限制Pod间通信配合Cilium的策略引擎做更细粒度的控制如只允许访问特定Service的特定端口。七、审计日志谁干了什么开启审计日志所有对API Server的请求都会记录# kube-apiserver启动参数--audit-log-path/var/log/kubernetes/audit.log--audit-log-maxage30--audit-log-maxbackup10--audit-policy-file/etc/kubernetes/audit-policy.yaml审计策略示例apiVersion:audit.k8s.io/v1kind:Policyrules:-level:RequestResponseresources:-group:resources:[pods,secrets]verbs:[create,update,delete]-level:Metadataresources:-group:resources:[pods]verbs:[get,list]定期审计日志可以发现异常行为如半夜有人批量删除Pod。八、安全检查清单检查项推荐配置匿名访问--anonymous-authfalseRBAC模式--authorization-modeRBAC客户端证书短期证书 自动轮换ServiceAccount Token启用BoundServiceAccountTokenVolumenamespace隔离不同团队/环境用不同namespacePod Security至少enforcebaselineNetworkPolicy配置namespace隔离策略审计日志记录敏感操作create/delete/update容器镜像只允许可信镜像仓库节点访问禁用SSH用kubectl exec代替九、小结Kubernetes安全是个系统工程没有一招鲜的银弹。核心思路认证做牢OIDC集成企业SSOServiceAccount Token绑定到PodRBAC做细按namespace隔离最小权限原则准入做硬Webhook拦截非法请求强制安全标准运行时做绝只读文件系统、Seccomp、NetworkPolicy多管齐下审计做全记录所有敏感操作定期回溯。记住安全没有终点只有持续的加固和监控。定期审计、及时升级、关注CVE才能在攻防博弈中立于不败之地。下一篇预告Kubernetes故障排查全景图——从Pod起不来到集群雪崩的诊断手册。