K8s安全加固实战：认证、授权、网络策略三维度解读

前言Kubernetes已成为企业云原生基础设施的标准但默认配置下的K8s集群存在诸多安全隐患。攻击者利用配置缺陷入侵集群后可横向扩展到整个基础设施。本文从认证Authentication、授权Authorization、**网络策略Network Policy**三个维度系统讲解K8s安全加固的实战方法。一、认证Authentication谁在访问API Server1.1 默认认证的问题K8s API Server默认不强制认证匿名用户只要知道API Server地址即可访问集群资源。在生产环境中必须关闭匿名认证# kube-apiserver 启动参数--anonymous-authfalse关闭匿名认证后所有请求都需要携带有效凭证。1.2 ServiceAccount Token认证Pod访问API Server通过ServiceAccount实现。默认每个Namespace有一个default ServiceAccount其Token具有该Namespace的读写权限。问题应用不需要API Server权限时Token仍在挂载。解决方案使用automountServiceAccountToken: false关闭自动挂载apiVersion:v1kind:ServiceAccountmetadata:name:my-app-sanamespace:productionautomountServiceAccountToken:false---apiVersion:apps/v1kind:Deploymentspec:template:spec:serviceAccountName:my-app-saautomountServiceAccountToken:false1.3 证书认证X.509 Client Certs对于需要集群管理权限的用户使用证书认证# 创建用户证书openssl req-new-newkeyrsa:4096\-keyoutadmin.key-nodes\-outadmin.csr\-subj/CNadmin/Osystem:masters# 签署证书openssl x509-req-inadmin.csr\-CA/etc/kubernetes/pki/ca.crt\-CAkey/etc/kubernetes/pki/ca.key\-CAcreateserial\-outadmin.crt-days365# 配置kubectl使用证书kubectl config set-credentials admin\--client-certificateadmin.crt\--client-keyadmin.key1.4 OIDC联合认证企业级方案大型企业推荐使用OIDC将K8s与现有身份提供商Okta、Keycloak、Azure AD集成# kube-apiserver OIDC配置--oidc-issuer-urlhttps://your-idp.com--oidc-client-idk8s-cluster--oidc-ca-file/etc/kubernetes/pki/oidc-ca.crt--oidc-username-claimemail--oidc-groups-claimgroups二、授权Authorization他们能做什么2.1 RBAC权限模型K8s使用RBAC基于角色的访问控制管理权限核心概念Role/ClusterRole定义一组权限规则RoleBinding/ClusterRoleBinding将规则绑定到用户/组/ServiceAccount示例只读Namespace权限apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:name:readonlynamespace:monitoringrules:-apiGroups:[]resources:[pods,services,configmaps]verbs:[get,list,watch]---apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:readonly-bindingnamespace:monitoringsubjects:-kind:Groupname:viewerscompany.comapiGroup:rbac.authorization.k8s.ioroleRef:kind:Rolename:readonlyapiGroup:rbac.authorization.k8s.io2.2 权限细化避免过度授权反面典型system:masters组拥有cluster-admin权限误用会导致完全失控。最佳实践遵循最小权限原则使用细粒度RBAC# 只能读取特定标签Pod的权限apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:name:pod-reader-with-labelnamespace:productionrules:-apiGroups:[]resources:[pods]verbs:[get,list]resourceNames:[]# 通过label selector限制2.3 Node授权模式K8s提供两种API Server授权模式模式说明适用场景Node限制kubelet只能访问自己Node上的资源默认需配合NodeRestriction插件RBAC使用角色绑定管理所有权限精细化控制场景# 启用NodeRestriction插件推荐--enable-admission-pluginsNodeRestriction2.4 权限审计定期检查过度授权的ServiceAccount# 列出所有具有cluster-admin权限的账户kubectl get clusterrolebinding-owide|grepcluster-admin# 检查某个SA的权限kubectl auth can-i--list--assystem:serviceaccount:default:default三、网络策略Network PolicyPod之间的流量管控3.1 默认网络模型的问题K8s默认网络是全连通模型任意Pod可以访问任意其他Pod。攻击者拿下单个Pod后可横向移动到整个集群。解决方案实施网络隔离策略。3.2 网络策略基础网络策略由CNI插件如Calico、Cilium实现声明式定义允许的流量apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:frontend-isolationnamespace:productionspec:podSelector:matchLabels:app:frontendpolicyTypes:-Ingress-Egressingress:# 只允许来自backend的流量-from:-podSelector:matchLabels:app:backendports:-protocol:TCPport:8080egress:# 只允许访问后端服务和DNS-to:-podSelector:matchLabels:app:backendports:-protocol:TCPport:8080-to:-namespaceSelector:matchLabels:kubernetes.io/metadata.name:kube-systemports:-protocol:UDPport:533.3 默认拒绝策略在安全要求高的Namespace中设置默认拒绝所有流量apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-allnamespace:productionspec:podSelector:{}# 空选择器 该Namespace所有PodpolicyTypes:-Ingress-Egress⚠️ 配置默认拒绝后必须显式开放每个工作负载需要的流量。3.4 微服务间的最小权限网络策略典型三层应用的网络策略模板App层 → 允许来自Ingress Controller的80/443 允许到API层的8080 拒绝其他所有 API层 → 允许来自App层的流量 允许到DB层的5432 允许到Redis的6379 拒绝其他所有 DB层 → 只允许来自API层的访问 拒绝其他所有包括同Namespace其他Pod# DB层网络策略apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:db-network-policynamespace:productionspec:podSelector:matchLabels:tier:databasepolicyTypes:-Ingressingress:-from:-podSelector:matchLabels:tier:apiports:-protocol:TCPport:5432四、综合加固检查清单检查项命令/操作标准关闭匿名认证kubectl get pod -A -o yaml | grep -i anonymous应返回空禁止默认SA Token挂载检查所有DeploymentautomountServiceAccountToken: false清理过度授权RBACkubectl get clusterrolebinding | grep cluster-admin只保留必要账户启用网络策略检查CNI配置每个Namespace至少有一条策略启用Audit日志kubectl logs -n kube-system kube-apiserver-*配置审计策略限制Pod特权模式PSP或OPA策略禁止privileged: true加密Secretetcd加密--encryption-provider-config五、工具推荐5.1 KubesecKubesec是一个K8s资源安全评分工具kubectl apply-fdeployment.yaml|kubesec score -输出安全评分0-100并列出具体风险项。5.2 kube-benchkube-bench对照CIS Kubernetes Benchmark检查集群配置kubectl apply-fhttps://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml kubectl logs job/kube-bench5.3 Falco运行时安全Falco监控K8s运行时异常行为# 检测容器内执行shell-rule:Detect Shell in Containerdesc:A shell was spawned in a container other than at container startcondition:spawned_process and container and proc.name bashoutput:Shell spawned in container (user%user.name command%proc.cmdline container%container.name)priority:WARNING结语K8s安全加固是一个持续过程不是一次性项目。建议先止血关闭匿名认证、实施网络隔离5分钟可完成再规范完善RBAC权限体系最后进阶集成OPA/Falco等运行时安全工具安全加固的投入会在安全事件发生时获得百倍回报。配图建议①认证流程图用户→API Server→认证插件→RBAC→资源②RBAC权限模型图Role/RoleBinding关系③网络策略示例架构图三层应用流量拓扑