Kubescape网络策略生成功能在K3s环境中的问题分析与解决方案

问题背景

Kubescape作为一款流行的Kubernetes安全工具，提供了自动生成网络策略(Network Policy)的功能。该功能通过node-agent组件周期性(默认2分钟)扫描集群网络流量，并生成NetworkNeighborhood和GeneratedNetworkPolicy等CRD资源。然而在K3s环境中，用户发现这些网络策略资源未能按预期生成。

环境与症状

典型的问题环境配置如下：

• 操作系统：Ubuntu 24.04.1
• Kubescape版本：3.0.18（Operator运行于v1.22.6）
• 集群类型：K3s

主要症状表现为：

• kubectl get generatednetworkpolicies -A命令返回"No resources found"
• 等待超过2分钟的策略生成周期后仍无网络策略生成
• 相关CRD已正确注册但无实例创建

根本原因分析

经过深入排查，发现问题主要由以下几个因素导致：

1. 节点代理权限不足：node-agent需要nodes/proxy API权限来访问kubelet的configz端点，以获取容器运行时信息。原始ClusterRole配置中缺少此权限。

2. 容器运行时目录访问问题：当使用LVM2等存储方案并将容器运行时目录设置为符号链接时，node-agent无法正确访问容器运行时数据，因为默认配置未挂载相关卷。

3. CRI套接字路径识别问题：K3s环境中容器运行时接口(CRI)套接字的默认路径与标准Kubernetes不同，导致node-agent无法正确定位。

解决方案

1. 完善RBAC配置

修改node-agent的ClusterRole，确保包含nodes/proxy资源权限：

rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/proxy  # 关键新增权限
  - services
  - endpoints
  - namespaces
  verbs: ["get", "watch", "list"]

2. 增强容器运行时访问

对于使用符号链接的容器运行时目录，需要为node-agent添加相应的volume挂载：

volumes:
- name: container-runtime
  hostPath:
    path: /var/lib/containerd  # 根据实际容器运行时路径调整
    type: Directory

3. 特权模式与安全配置

确保node-agent以足够权限运行：

securityContext:
  privileged: true
  seLinuxOptions:
    type: spc_t
  capabilities:
    add:
    - SYS_ADMIN
    - SYS_PTRACE
    - NET_ADMIN
    - SYSLOG
    - SYS_RESOURCE
    - IPC_LOCK
    - NET_RAW

4. 网络策略功能启用

在Helm values中显式启用网络策略功能并配置API服务器地址：

global:
  networkPolicy:
    enabled: true
    apiServerIP: <Kubernetes Service ClusterIP>

验证与测试

实施上述修改后，可通过以下命令验证功能是否正常：

1. 检查node-agent日志是否有错误：

kubectl logs -n kubescape <node-agent-pod>

2. 确认NetworkNeighborhood资源生成：

kubectl get networkneighborhoods -A

3. 检查特定部署的网络策略：

kubectl get generatednetworkpolicies <deployment-name> -n <namespace>

最佳实践建议

1. 环境适配：在非标准Kubernetes发行版(如K3s)上部署时，特别注意容器运行时路径、权限模型等差异。

2. 渐进式部署：先在小范围测试网络策略生成功能，确认无误后再推广到生产环境。

3. 监控与告警：对node-agent的运行状态设置监控，确保网络策略生成服务持续可用。

4. 策略审查：自动生成的网络策略应经过安全团队审查，避免过度限制或不足的保护。

通过以上措施，可以确保Kubescape的网络策略自动生成功能在K3s等环境中稳定运行，为集群提供动态、精准的网络隔离能力。