Logo

菜单

u1timate
发布于 2026-01-04 / 5 阅读
0
0

3 安全加固

#容器

牢记最小权限原则、纵深防御策略和持续审计是保障这些核心组件安全的关键。

0x01 API Server 安全加固

API Server 是Kubernetes集群的控制面入口，所有对集群的操作都必须通过它。因此，对其进行加固至关重要。

  • 认证和授权

    • 强制使用双向 TLS 认证

    • 使用 RBAC 进行精细化授权

  • 准入控制器

    • PodSecurity 准入控制器：在Kubernetes 1.23+版本中推荐使用，替代了废弃的Pod Security Policies (PSP)。它允许在命名空间级别强制执行 privileged, baseline, restricted 等Pod安全标准。例如，强制所有Pod使用非root用户、限制特权容器等

    • NodeRestriction 准入控制器：防止 Kubelet 伪造或修改节点上的 Pod 和 Service 对象。它限制了 Kubelet 仅能修改和读取其自身节点相关的 API 对象。

    • LimitRange/ResourceQuota 准入控制器：虽然主要用于资源管理，但也间接提高了安全性，防止单一应用耗尽集群资源，造成拒绝服务。

  • 网络访问控制

    • 防火墙规则：仅允许受信任的主机和网络（例如控制面组件所在的VPC）访问API Server的端口（默认为6443或8080）。

    • 网络隔离：API Server通常不应暴露在公共互联网上，或通过严格的云防火墙和WAF进行保护。

  • 审计日志

    • 配置审计策略，记录关键操作（如创建、修改、删除 Pod/Deployment）。

    • 将审计日志发送到集中的日志管理系统（如ELK Stack或Splunk）。

0x02 Etcd 安全加固

Etcd 是Kubernetes集群的关键数据存储，包含所有集群状态、配置和敏感信息（如Secrets）。保护 Etcd 等同于保护整个集群。

  • 强制使用双向 TLS 加密通信

    • 客户端到服务器：确保API Server和其他客户端与Etcd之间使用TLS加密通信，并进行客户端证书认证。

    • 节点间通信 (Peer Communication)：如果Etcd集群有多个节点，它们之间的通信也必须使用TLS加密和认证。

  • 访问控制与网络隔离

    • 限制访问源：只允许K8s API Server访问Etcd，并通过防火墙规则严格限制其他主机的访问。

    • 网络分段：将Etcd节点部署在与工作节点逻辑隔离的网络段中，最好是独立的管理网络。

  • 定期备份与恢复

0x03 worker 节点加固

工作节点是运行Pod的实际计算单元，它们的安全性直接影响到Pod中应用的安全性。

  • 操作系统层面的加固

    • 遵循 CIS Benchmarks：针对所使用的操作系统（如 CentOS、Ubuntu）应用 CIS (Center for Internet Security) 基准安全配置。这包括禁用不必要的服务、最小化安装、强化文件系统权限等。

    • 最小化安装：工作节点上只安装运行Kubelet、容器运行时（Docker/Containerd）和必要工具所需的软件包，减少攻击面。

    • 内核参数调优：例如，禁用不必要的网络协议栈，启用 rp_filter 等。

  • kubectl 安全配置： Kubelet 是运行在每个工作节点上的代理，负责与API Server通信并管理Pod。

    • 强制使用双向 TLS 认证：Kubelet 应该使用证书向 API Server 进行认证，API Server 也应验证 Kubelet 证书。

    • 禁用匿名请求：Kubelet 默认接受匿名请求，应通过 --anonymous-auth=false 禁用（如果开启了 webhook 或 RBAC 授权，匿名用户通常也没有权限，但仍建议禁用）。

    • 禁用只读端口：Kubelet 提供了只读端口（默认10255，该端口是一个完全不需要认证的端口，暴露了大量节点信息。），应通过 --read-only-port=0 禁用。

    • 授权模式：Kubelet 的 --authorization-mode 应设置为 Webhook（最常用） 或 RBAC，而不是 AlwaysAllow。

    • NodeRestriction 准入控制器：结合 API Server 端的 NodeRestriction 准入控制器，限制 Kubelet 只能访问和修改其自身节点上的资源。NodeRestriction 需要在 API Server 启动参数中启用：--enable-admission-plugins=NodeRestriction

示例：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false # 禁用匿名访问
  webhook:
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt # 信任的CA证书
authorization:
  mode: Webhook # 使用 Webhook 授权模式
cgroupDriver: systemd
clusterDNS: # ...
clusterDomain: cluster.local
containerRuntimeEndpoint: "unix:///var/run/containerd/containerd.sock"
featureGates:
  # ...
logging:
  # ...
# readOnlyPort: 0 # 可以通过命令行参数禁用
port: 10250
readOnlyPort: 0 # 禁用只读端口
rotateCertificates: true # 自动轮换 Kubelet 证书
serverTLSBootstrap: true # Kubelet 向 API Server 请求证书
# ...

修改了现有配置文件，记得重启Kubelet服务以应用更改：sudo systemctl restart kubelet

  • 容器运行时安全

    • Docker/Containerd 加固：遵循其官方安全指南，例如限制容器的默认能力集（capabilities）、使用 seccomp 配置文件、AppArmor 或 SELinux。

    • 镜像签名与验证：确保只运行来自可信源的容器镜像。

    • 使用非特权容器：避免在 Pod 中使用 privileged: true。

    • 限制资源：为容器设置 CPU 和内存限制，防止资源耗尽攻击。

  • SSH 访问控制

    • 禁用密码认证：仅允许通过密钥对进行 SSH 登录。

    • 禁用 Root 登录：不允许直接以 root 用户通过 SSH 登录。

    • 使用堡垒机：通过集中的堡垒机访问工作节点，并记录所有会话。

    • 定期轮换 SSH 密钥。

  • 文件系统权限与不可变基础设施

    • 限制文件系统权限：确保工作节点上的关键目录和文件（如 /etc/kubernetes, /var/lib/kubelet）具有严格的权限设置。

    • 不可变基础设施：尽可能将工作节点视为不可变（Immutable Infrastructure）。当需要更新或更改时，不是修改现有节点，而是创建新的、已更新的节点并替换旧节点

  • 网络安全

    • 防火墙规则：配置防火墙（如 iptables、firewalld）以限制工作节点间的通信，只允许必要的端口开放。

    • 网络策略 (Network Policies)：在Kubernetes层面，使用网络策略限制Pod之间的通信。

  • 补丁管理

    • 及时更新操作系统和K8s组件：定期应用安全补丁和更新，修复已知漏洞。

    • 漏洞扫描：定期对工作节点进行操作系统和软件包的漏洞扫描。

0x04 审计策略

4.1 配置Kubernetes审计策略

审计策略是一个YAML文件，包含一系列规则，每个规则定义了匹配的事件类型和对应的审计级别

  • 审计级别

    • None：不记录任何与此规则匹配的事件。

    • Metadata：只记录请求的元数据（如请求的用户、时间戳、资源、动词），不记录请求或响应体。

    • Request：记录事件的元数据和请求体，但不记录响应体。适用于非敏感信息资源的变更请求。

    • RequestResponse：记录事件的元数据、请求体和响应体。这是最详细的级别，但可能包含敏感信息，并增加日志量和存储成本。

  • 审计规则（每个规则可以基于以下条件匹配事件：）

    • users：匹配特定用户或服务账号。

    • groups：匹配特定用户组。

    • resources：匹配特定资源类型（如pods、deployments、secrets）。

    • verbs：匹配特定的操作动词（如get、list、create、update、delete）。

    • nonResourceURLs：匹配非资源请求（如/metrics、/version）。

    • omitStages：指定在审计生命周期的哪个阶段不记录日志。

示例审计策略文件 audit-policy.yaml 

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # 1. 忽略对 /healthz 和 /version 等健康检查和版本信息的请求,减少噪音
  - level: None
    users: ["system:kube-proxy", "system:unsecured"]
    urls:
      - "/healthz*"
      - "/version"
      - "/api" # 忽略某些内部API，具体按需配置

  # 2. 忽略kube-controller-manager、kube-scheduler和kube-apiserver的服务账号对watch请求的审计
  - level: None
    users:
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
      - "system:apiserver"
    verbs: ["watch"]

  # 3. 记录对secrets、configmaps和tokenreviews的读写请求的所有细节（请求和响应体）
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
      - group: "authentication.k8s.io"
        resources: ["tokenreviews"]

  # 4. 记录所有对pods、deployments、services等核心资源的请求和响应（不含响应体）
  - level: Request
    resources:
      - group: ""
        resources: ["pods", "services", "deployments", "namespaces"]

  # 5. 记录所有其他请求的元数据，作为默认规则
  - level: Metadata
    omitStages:
      - "RequestReceived"

4.2 启用审计日志

在kube-apiserver的启动参数中指定审计策略文件和日志输出位置：

kube-apiserver \
  --advertise-address=192.168.1.10 \
  --bind-address=0.0.0.0 \
  --secure-port=6443 \
  --allow-privileged=true \
  \
  # 认证相关
  --client-ca-file=/etc/kubernetes/pki/ca.crt \
  --tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
  --tls-private-key-file=/etc/kubernetes/pki/apiserver.key \
  --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key \
  \
  # 授权模式
  --authorization-mode=Node,RBAC \
  \
  # Admission 控制器
  --enable-admission-plugins=NodeRestriction \
  \
  # 审计日志配置
--audit-policy-file=/etc/kubernetes/audit-policy.yaml \
--audit-log-path=/var/log/kubernetes/audit.log \
--audit-log-maxage=30 \
--audit-log-maxbackup=10 \
--audit-log-maxsize=100

  • --audit-policy-file：审计策略文件的路径。

  • --audit-log-path：审计日志的输出路径。

  • --audit-log-maxage：日志文件保留的最大天数。

  • --audit-log-maxbackup：保留的最大日志文件数量。

  • --audit-log-maxsize：每个日志文件的最大大小（MB）。

4.3 其他组件的日志管理

除了API服务器的审计日志，Kubernetes集群中的其他组件也生成大量重要的日志，它们对于理解集群行为、故障排查和安全分析至关重要。

  • kube-apiserver：除了审计日志外，其自身的运行日志包含了API服务器的内部错误、启动信息、健康检查等。

  • kube-controller-manager：控制器管理器日志，记录了控制器（如Deployment Controller、Node Controller）的协调活动，对于理解资源状态变化和潜在问题很有用。

  • kube-scheduler：调度器日志，记录了Pod的调度决策和可能遇到的问题。

  • kubelet：运行在每个工作节点上的kubelet日志，包含了Pod的生命周期管理、容器运行时交互、卷挂载、网络配置等关键信息。这些日志对于节点层面的安全事件和故障排查至关重要。

  • kube-proxy：服务代理日志，记录了网络代理和负载均衡的配置信息。

  • CoreDNS/Kube-DNS：集群DNS服务的日志，用于排查服务发现问题。

  • 容器运行时（如Containerd/CRI-O/Docker）：记录容器的启动、停止、错误等信息。

  • 应用程序日志：运行在Pod中的应用程序自身产生的日志。

2 kubernetes 介绍

评论