如何在Kubernetes中实现容器级网络策略以隔离同Pod内容器？

针对你遇到的同Pod内不可信sidecar容器可访问私有Kafka集群的问题，这里提供几个可行的落地方案：

1. 基于Linux UID的iptables细粒度隔离 #

同Pod内的容器共享网络命名空间，但每个容器的进程运行在独立的UID空间（可通过Security Context指定）。利用这一点可以在Pod内配置iptables规则，限制特定UID的进程访问Kafka地址：

• 给consumer容器指定固定运行UID（比如securityContext.runAsUser: 1000），sidecar容器指定不同UID（比如runAsUser: 2000）。
• 在Pod中添加一个init容器，在共享的网络命名空间中执行iptables规则：

  # 拒绝UID为2000的进程访问Kafka集群的IP段和端口
  iptables -A OUTPUT -m owner --uid-owner 2000 -d <KAFKA_SUBNET> -p tcp --dport <KAFKA_PORT> -j DROP
  # 允许sidecar与consumer的本地通信（假设consumer监听127.0.0.1:8080）
  iptables -A OUTPUT -m owner --uid-owner 2000 -d 127.0.0.1 -p tcp --dport 8080 -j ACCEPT
  

• 确保init容器拥有NET_ADMIN权限，才能修改iptables规则。

2. 用AppArmor/Seccomp限制sidecar的网络权限 #

通过Kubernetes的安全策略，给sidecar容器绑定严格的AppArmor或Seccomp profile，限制其网络访问能力：

• AppArmor：创建一个profile，仅允许sidecar连接localhost的特定端口（即consumer的监听端口），禁止所有外部网络连接：

  profile sidecar-restricted flags=(attach_disconnected) {
    # 基础网络权限
    network inet tcp,
    # 仅允许连接本地8080端口
    network inet tcp dst 127.0.0.1/32 port 8080,
    # 拒绝其他所有网络连接
    deny network inet tcp,
    # 其他必要的文件/系统调用权限
    ...
  }
  

  在sidecar容器的Security Context中通过注解指定profile：container.apparmor.security.beta.kubernetes.io/sidecar: <自定义profile名称>。
• Seccomp：使用自定义seccomp profile，禁止sidecar执行connect系统调用（或仅允许连接本地地址），从系统调用层面阻断外部网络访问。

3. 拆分Pod为独立实例（备选） #

如果架构允许，将consumer和sidecar拆分为两个独立Pod：

• 将consumer Pod部署在私有子网，配置Network Policy仅允许其访问Kafka集群。
• 将sidecar Pod部署在指定子网，配置Network Policy仅允许其与consumer Pod通信，禁止访问Kafka子网。
• 通过Kubernetes Service或本地通信机制（如共享PV、轻量消息队列）实现两个Pod间的数据转发。

4. 强化Kafka的认证与授权（补充方案） #

在现有认证基础上进一步加固：

• 仅给consumer容器分配Kafka的访问凭证（证书、API密钥），并通过Security Context设置文件权限，限制sidecar容器无法读取这些凭证文件。
• 在Kafka端配置IP白名单，仅允许consumer Pod所在的IP段访问，即使sidecar能发起请求也会被Kafka直接拒绝。

内容的提问来源于stack exchange，提问作者krish advani