Linux上K8S安全策略如何实施 - 问答

Linux上K8s安全策略实施路线图

一基础系统与节点加固

保持系统与组件更新：持续升级 Linux 与 Kubernetes 组件（如 kubelet、kubeadm、kubectl），及时修补漏洞。
禁用 Swap：Kubelet 要求节点禁用 Swap，执行 swapoff -a 并在 /etc/fstab 注释 swap 行，避免稳定性与安全风险。
内核网络参数：开启桥接流量进入 iptables，启用转发。
示例：
cat >> /etc/sysctl.d/kubernetes.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF
sysctl -p
防火墙与端口最小化：使用 UFW 或 firewalld 仅开放必要端口（如 22/SSH、6443/API、10250/Kubelet、2379-2380/etcd、53/DNS、30000-32767/NodePort 可选），默认拒绝入站。
主机加固：仅密钥登录、关闭不必要服务与端口、最小权限账户、启用日志与审计。
以上措施能显著降低节点被入侵与横向移动的风险，并为后续策略落地提供稳定基础。

二身份与访问控制 RBAC

最小权限与分层授权：遵循最小权限原则，优先使用 Role/RoleBinding 收敛到命名空间，必要时再用 ClusterRole/ClusterRoleBinding。
避免滥用高权限：谨慎授予 cluster-admin，优先使用内置 view/edit/admin 或自定义细粒度规则。
管理 default ServiceAccount：生产应用避免使用 default SA；如无需调用 API，设置 automountServiceAccountToken: false。
权限验证与排查：使用 kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa> 校验权限；通过 kubectl describe rolebinding/clusterrolebinding 与 kubectl-who-can 等工具审计与排查。
云上场景的双层授权：在 ACK 等托管集群中，需同时完成 RAM（谁能进集群）与 RBAC（能做什么）授权，形成从云资源到集群资源的完整授权链。
RBAC 是集群权限的“门禁与分权”核心，落地时要以“最小权限 + 可审计 + 可验证”为目标。

三网络策略与隔离

前提条件：部署支持 NetworkPolicy 的 CNI（如 Calico、Cilium）；注意 Flannel 默认不支持 NetworkPolicy，需更换或叠加方案。
策略范式：按“默认拒绝、按需放行”设计；为关键业务（如 数据库）仅允许来自 前端/业务 标签的入站端口（如 3306/TCP），并限制出站到必要 IP/CIDR 与端口（如 DNS 53）。
典型策略示例：
- 命名空间默认隔离（同一命名空间内互通）：
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: allow-same-namespace
  namespace: default
  spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
  ingress: [{ from: [{ podSelector: {} }] }]
  egress: [{ to: [{ podSelector: {} }] }]
- 仅允许 app=client 访问 app=web 的 80 端口：
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: web-access-policy
  namespace: default
  spec:
  podSelector: { matchLabels: { app: web } }
  policyTypes: [Ingress]
  ingress:
  - from: [{ podSelector: { matchLabels: { app: client } }]
    ports: [{ protocol: TCP, port: 80 }]
- 限制数据库出站到特定网段与端口：
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: restrict-egress
  namespace: default
  spec:
  podSelector: { matchLabels: { app: backend } }
  policyTypes: [Egress]
  egress:
  - to: [{ ipBlock: { cidr: 10.0.0.0/24 } }]
    ports: [{ protocol: TCP, port: 5432 }]
验证与排错：创建临时客户端 Pod 进行连通性测试（如 wget/curl），使用 kubectl get/describe networkpolicy 与 CNI 日志定位问题。
网络策略将“谁能和谁通信、用什么端口”收敛为白名单，是遏制横向渗透的关键防线。

四镜像与运行时安全

镜像与漏洞治理：在 CI/CD 中集成 镜像扫描（如 Clair、Trivy、商业扫描器），阻断含高危 CVE 的镜像进入生产；镜像仓库启用签名与可信源。
运行时防护与取证：部署 Falco/Sysdig 等运行时安全工具，检测异常进程、系统调用与容器逃逸行为，保留审计线索。
安全上下文与最小权限容器：在 Pod/容器 SecurityContext 中启用 runAsNonRoot、readOnlyRootFilesystem、drop capabilities、seccomp/AppArmor/SELinux 等，减少攻击面。
加密与密钥管理：启用 TLS 保护控制面与数据面通信；Secrets 使用 KMS 或外部密钥管理进行加密与轮换；敏感数据避免在环境变量中明文存放。
审计与监控：开启 Kubernetes 审计日志，集中收集与告警；对关键资源（如 Secrets、RBAC 变更、Namespace 创建）设置审计与告警策略。
持续运营：建立 漏洞管理 与 合规巡检 流程，定期复盘权限、策略与镜像风险，形成闭环改进。
这些措施覆盖“构建—分发—运行—审计”全生命周期，显著降低容器逃逸与数据泄露的概率。

0 赞

0 踩