Kubernetes服务访问控制咨询：如何实现类VM风格的ACL权限管控？

没问题！Kubernetes 完全支持实现类似传统VM环境中ACL的服务间访问权限管控，甚至能做到比传统ACL更灵活的细粒度控制。下面给你梳理几个最常用的方案：

1. Kubernetes NetworkPolicy（原生“ACL”方案） #

这是K8s官方提供的原生网络管控机制，完全对标传统ACL的核心需求——基于源、目标、端口来限制流量。它通过标签选择器匹配Pod/Service，只允许符合规则的流量通过。

举个例子，假设你的Service B对应的Pod都带有标签 app=service-b，Service A的Pod带有 app=service-a，你可以创建一个NetworkPolicy只允许A访问B，拒绝C的请求：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-service-a-to-service-b
  namespace: default # 假设服务都在default命名空间
spec:
  podSelector:
    matchLabels:
      app: service-b # 目标是Service B的Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: service-a # 只允许来自Service A的Pod的流量
    ports:
    - protocol: TCP
      port: 80 # 只允许访问80端口

这个规则生效后，Service C的Pod就无法访问Service B了，完美实现类似ACL的管控。

注意：NetworkPolicy需要你的K8s集群使用支持它的CNI插件（比如Calico、Cilium、Weave Net），如果是默认的Flannel可能需要额外配置才能支持。

2. 服务网格（Istio/Linkerd）—— 更精细化的管控 #

如果你的集群服务数量多、需要更复杂的访问规则（比如基于请求头、用户身份、API路径的管控），服务网格是更好的选择。以Istio为例，它的AuthorizationPolicy可以实现远超传统ACL的细粒度控制：

比如不仅限制源服务，还只允许带有特定请求头的GET请求访问Service B的指定路径：

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: service-b-access-control
  namespace: default
spec:
  selector:
    matchLabels:
      app: service-b
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/service-a-sa"] # 基于服务账户精准匹配
    to:
    - operation:
        methods: ["GET"]
        paths: ["/api/v1/*"]

服务网格还能提供流量监控、链路追踪等附加能力，但需要额外部署和学习成本，适合中大型集群。

3. 第三方CNI插件的高级ACL能力 #

像Calico、Cilium这类CNI插件本身就自带强大的网络管控能力，除了支持K8s NetworkPolicy，还能直接配置基于IP段、协议的底层ACL规则，完全对标传统VM环境的ACL配置逻辑。

比如Calico的GlobalNetworkPolicy可以跨命名空间管控流量，适合需要更底层网络控制的场景。

总结 #

• 如果只是简单的服务间访问限制，优先用Kubernetes NetworkPolicy，原生、轻量、无额外依赖；
• 如果需要复杂的细粒度控制或附加能力，考虑服务网格；
• 如果需要底层网络级的ACL规则，选择支持高级管控的CNI插件。

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