K8s安全加固实战：认证、授权、网络策略三维度解读
前言
Kubernetes已成为企业云原生基础设施的标准，但默认配置下的K8s集群存在诸多安全隐患。攻击者利用配置缺陷入侵集群后，可横向扩展到整个基础设施。本文从认证（Authentication）、授权（Authorization）、**网络策略（Network Policy）**三个维度，系统讲解K8s安全加固的实战方法。
一、认证（Authentication）：谁在访问API Server
1.1 默认认证的问题
K8s API Server默认不强制认证，匿名用户只要知道API Server地址即可访问集群资源。在生产环境中，必须关闭匿名认证：
# kube-apiserver 启动参数--anonymous-auth=false关闭匿名认证后，所有请求都需要携带有效凭证。
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"/CN=admin/O=system: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-certificate=admin.crt\--client-key=admin.key1.4 OIDC联合认证（企业级方案）
大型企业推荐使用OIDC将K8s与现有身份提供商（Okta、Keycloak、Azure AD）集成：
# kube-apiserver OIDC配置--oidc-issuer-url=https://your-idp.com--oidc-client-id=k8s-cluster--oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt--oidc-username-claim=email--oidc-groups-claim=groups二、授权（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:"viewers@company.com"apiGroup: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-plugins=NodeRestriction2.4 权限审计
定期检查过度授权的ServiceAccount：
# 列出所有具有cluster-admin权限的账户kubectl get clusterrolebinding-owide|grepcluster-admin# 检查某个SA的权限kubectl auth can-i--list--as=system:serviceaccount:default:default三、网络策略（Network Policy）：Pod之间的流量管控
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挂载 | 检查所有Deployment | automountServiceAccountToken: false |
| 清理过度授权RBAC | kubectl get clusterrolebinding | grep cluster-admin | 只保留必要账户 |
| 启用网络策略 | 检查CNI配置 | 每个Namespace至少有一条策略 |
| 启用Audit日志 | kubectl logs -n kube-system kube-apiserver-* | 配置审计策略 |
| 限制Pod特权模式 | PSP或OPA策略 | 禁止privileged: true |
| 加密Secret | etcd加密 | --encryption-provider-config |
五、工具推荐
5.1 Kubesec
Kubesec是一个K8s资源安全评分工具：
kubectl apply-fdeployment.yaml|kubesec score -输出安全评分（0-100），并列出具体风险项。
5.2 kube-bench
kube-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关系）；③网络策略示例架构图（三层应用流量拓扑）