Kubernetes在Ubuntu上的安全配置

Ubuntu 上 Kubernetes 的安全配置清单

一 基础系统与内核加固

• 时间同步：部署 NTP/chrony，保证节点时间一致，避免因时间漂移导致证书校验、审计与调度异常。示例：sudo apt install ntp ntpdate && sudo ntpdate ntp1.aliyun.com。
• 禁用 Swap：Kubernetes 要求关闭 Swap，编辑 /etc/fstab 注释 swap 行并执行 swapoff -a，否则会影响 kubelet 调度与稳定性。
• 内核网络参数：启用桥接流量进入 iptables 并开启转发，创建 /etc/sysctl.d/kubernetes.conf：
  net.bridge.bridge-nf-call-ip6tables = 1
  net.bridge.bridge-nf-call-iptables = 1
  net.ipv4.ip_forward = 1
  执行 sysctl -p 生效。
• 容器运行时：优先使用 Containerd（或 Docker），安装后配置 cgroups、镜像仓库与镜像拉取凭据，减少供应链风险。
• 安全基线：保持 系统与安全补丁 及时更新，最小化安装、关闭不必要的端口与服务，仅保留运维与管理必需组件。

二 防火墙与端口最小化

• 启用 UFW 并设置默认拒绝入站：sudo ufw default deny incoming && sudo ufw enable。
• 仅开放必要端口（示例为内网网段 10.0.0.0/24，管理网段 192.168.1.0/24）：
  • 22/TCP SSH：仅管理网段
  • 6443/TCP API Server：仅内网/管理网段
  • 10250/TCP Kubelet API：仅内网节点
  • 2379–2380/TCP etcd：仅主节点之间
  • 53/TCP/UDP CoreDNS：仅内网
  • NodePort 30000–32767/TCP：仅在需要时开放并限制来源
• 示例规则：
  • sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
  • sudo ufw allow from 10.0.0.0/24 to any port 6443 proto tcp
  • sudo ufw allow from 10.0.0.0/24 to any port 10250 proto tcp
  • sudo ufw allow from <master1>,<master2> to any port 2379 proto tcp
  • sudo ufw allow from 10.0.0.0/24 to any port 53 proto tcp,udp
• 不使用 NodePort 时可关闭该端口段：sudo ufw deny 30000:32767/tcp。

三 加密通信与证书管理

• 全组件启用 TLS：确保 API Server、etcd、kubelet、kube-proxy、controller-manager、scheduler 之间以及与客户端均通过证书进行双向认证与加密。
• 初始化集群时正确配置证书 SAN（如外网域名/IP）：
  sudo kubeadm init --apiserver-advertise-address=<内网IP> --apiserver-cert-extra-sans=<外网IP/域名> --pod-network-cidr=10.244.0.0/16。
• 引导与轮换：
  • 创建短期 bootstrap token：sudo kubeadm token create --validity 24h --print-join-command。
  • 检查证书有效期：sudo kubeadm certs check-expiration。
  • 证书续期：sudo kubeadm certs renew all，随后重启控制面静态 Pod 与 kubelet：
    • systemctl restart kubelet
    • kubectl delete pod -n kube-system -l k8s-app=kube-apiserver
    • kubectl delete pod -n kube-system -l k8s-app=kube-controller-manager
    • kubectl delete pod -n kube-system -l k8s-app=kube-scheduler
• 严禁使用 insecure-port（8080） 或未加密访问方式，避免明文管理通道。

四 网络策略与命名空间隔离

• 部署 Calico 等支持 NetworkPolicy 的 CNI 插件：
  • 下载并应用：curl https://docs.projectcalico.org/manifests/calico.yaml -O && kubectl apply -f calico.yaml。
• 默认拒绝基线：先实施全局默认拒绝，再按需放行。
  • Calico 全局策略（拒绝所有入/出站）：
    apiVersion: projectcalico.org/v3
    kind: GlobalNetworkPolicy
    metadata:
    name: default-deny
    spec:
    selector: all()
    types:
    - Ingress
    - Egress
  • DNS 例外（保证解析可用）：
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
    name: allow-dns
    namespace: default
    spec:
    podSelector: {}
    policyTypes:
    - Ingress
    ingress:
    - from:
    - namespaceSelector:
    matchLabels:
    name: kube-system
    - podSelector:
    matchLabels:
    k8s-app: kube-dns
    ports:
    - protocol: TCP
    port: 53
    - protocol: UDP
    port: 53
• 命名空间隔离示例（如 database）：默认拒绝入/出站，仅放行 DNS。分阶段推广策略，先测试后生产。

五 RBAC 最小权限与审计监控

• RBAC 最小权限：按“最小够用”为团队与系统组件分配 Role/ClusterRole，通过 RoleBinding/ClusterRoleBinding 绑定。
  • 示例（开发命名空间只读 + 部分写权限）：
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
    namespace: dev-namespace
    name: dev-namespace-role
    rules:
    • apiGroups: [“”]
      resources: [“pods”,“services”]
      verbs: [“get”,“list”,“create”,“update”,“delete”]
    • apiGroups: [“apps”]
      resources: [“deployments”]
      verbs: [“get”,“list”,“create”,“update”,“delete”]
    • apiGroups: [“”]
      resources: [“configmaps”]
      verbs: [“get”,“list”]

    ---

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
    name: dev-namespace-binding
    namespace: dev-namespace
    subjects:
    • kind: User
      name: dev-team
      apiGroup: rbac.authorization.k8s.io
      roleRef:
      kind: Role
      name: dev-namespace-role
      apiGroup: rbac.authorization.k8s.io
  • 限制 default ServiceAccount 权限，避免工作负载“自动获得”过高权限。
• 审计与监控：
  • 启用 API Server 审计日志（示例策略，记录敏感操作与元数据）：
    apiVersion: audit.k8s.io/v1
    kind: Policy
    omitStages:
    • “RequestReceived”
      rules:
    • level: RequestResponse
      verbs: [“delete”,“deletecollection”,“patch”,“update”]
    • level: Metadata
      verbs: [“get”,“list”,“watch”]
      users: [“system:kube-proxy”]
    • level: None
      verbs: [“watch”]
      users: [“system:kube-proxy”]
      resources:
      • group: “”
        resources: [“endpoints”,“services”]
  • 结合 监控系统与告警（如节点资源、Pod 异常重启、准入控制拦截）形成闭环。

六 运行时与镜像安全

• 镜像治理：仅从 可信仓库 拉取镜像，启用镜像签名与可信源校验，定期更新基础镜像修复 CVE。
• 敏感信息管理：使用 Secrets（结合 KMS 或外部密钥管理服务）、ConfigMap 管理配置，避免明文与硬编码。
• 运行时防护：
  • 启用 Pod Security Admission（PSA） 或替代机制，限制特权容器、主机网络/挂载、Root 用户等。
  • 容器运行时启用 seccomp/AppArmor/SELinux（Ubuntu 常用 AppArmor），减少内核攻击面。
  • 资源与隔离：为容器设置 requests/limits，使用 SecurityContext 指定非 root 用户、只读根文件系统、最小能力集。
• 持续合规：定期执行 CIS/K8s 基线 扫描与配置审计，结合准入控制（OPA/Gatekeeper、Kyverno）强制策略落地。