云原生 Cilium NetworkPolicy 限制访问 怎样处理

Cilium NetworkPolicy 限制访问时，先不要急着把规则改成“全部允许”。更稳妥的处理顺序是：先判断被限制的是入站还是出站，再确认策略到底选中了哪些 Pod，最后把目标身份、端口和必要依赖分别写成允许规则。只要一条策略带有 ingress 或 egress，对应方向就可能从默认放行转为只允许白名单。

官方地址：https://docs.cilium.io/en/stable/security/policy/

下面用 frontend 访问 api:8080 的场景说明边界。示例是原创配置示意，不代表已经在某个集群中执行。

先分清 ingress、egress 与默认拒绝

对 api 来说，frontend 发起的连接是 ingress；对 frontend 来说，同一条连接又是 egress。两边的规则不是一回事：只写 frontend 的出站允许，并不能替代 api 的入站允许；只写 api 的入站允许，也不能自动放开 frontend 的其它出站目标。

Cilium 的默认策略按方向生效。某个规则选中端点并包含 ingress 时，该端点的入站会进入默认拒绝状态；包含 egress 时，出站也会进入默认拒绝状态。允许连接的回复包属于同一条有状态连接，但反方向主动新建连接仍需要自己的规则。

用选择器把限制范围缩到目标工作负载

排查“明明写了规则却访问不了”时，先看 endpointSelector，再看规则中的 fromEndpoints 或 toEndpoints。在 Kubernetes 中，标签选择还要结合命名空间理解：策略对象本身是命名空间级资源时，空的端点选择器默认只作用于策略所在命名空间；跨命名空间访问则应显式写出对端命名空间标签。

例如，目标 API 位于 app 命名空间，应用标签为 app: api，前端标签为 app: frontend。下面的策略只把 API 的 8080 入站开放给同一命名空间中的 frontend：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-from-frontend
  namespace: app
spec:
  # 只选中 app 命名空间内的 API Pod。
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        # 对端标签决定哪些工作负载可以发起入站连接。
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            # 端口规则把允许范围收窄到应用实际监听端口。
            - port: "8080"
              protocol: TCP

这条规则并不表示 api 的所有流量都开放：它只描述入站来源与 8080 端口。若 frontend 自身已经被 egress 策略选中，还需要在 frontend 一侧写出站规则，否则请求可能在离开 frontend 时就被拒绝。

分别配置 API 入站与 frontend 出站

更容易维护的做法是让两侧规则保持对称，但不要把所有实体混成一个“大放行”。API 的入站只表达“谁能访问我”；frontend 的出站只表达“我能访问谁”。两条规则共同构成一条受限的应用关系。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-api
  namespace: app
spec:
  # 只选中前端 Pod，避免把出站白名单施加给其它应用。
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        # 同时限定对端身份，避免只按端口放大访问范围。
        - matchLabels:
            app: api
      toPorts:
        - ports:
            # 只允许前端主动连接 API 的 8080/TCP。
            - port: "8080"
              protocol: TCP

如果规则选中了不同命名空间的对端，应在 matchLabels 中补充 io.kubernetes.pod.namespace。不要只写一个容易复用的 app 标签就假定它足以表达边界。

给 DNS 和外部依赖留下明确出口

frontend 一旦进入 egress 默认拒绝，DNS 查询也会受到影响。此时应用表现可能是“访问 API 超时”，但真正缺失的是到 kube-dns 的 UDP 或 TCP 53 出口。DNS 规则应该单独存在，并且只指向集群 DNS 的身份标签。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-dns
  namespace: app
spec:
  # 该规则只负责 DNS，不把其它外部访问顺带放开。
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            # DNS 通常使用 UDP；保留 TCP 53 以覆盖较大的响应场景。
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP

对公网或集群外服务，优先根据真实依赖写 toFQDNs、toCIDR 或明确实体规则，不要把 toEntities: all 当作临时排障的长期方案。若同时存在 allow 与 deny，Cilium 的 deny 规则优先级更高；一条看似正确的允许规则仍可能被匹配到的 deny 覆盖。

从策略对象和被拒绝流量两侧排查

排查时建议固定看四件事：目标 Pod 是否由 Cilium 管理；endpointSelector 是否命中；端口和协议是否一致；是否有更高优先级的 deny。使用 hostNetwork 的 Pod，或在 Cilium 部署前就启动且未重新创建的 Pod，可能不按普通端点策略处理。

# 查看已加载的策略，先确认对象与规则是否出现在 Cilium 视角中。
cilium policy get

# 只观察被策略丢弃的流量，重点对照源、目的、端口和拒绝原因。
hubble observe --verdict DROPPED --follow

如果 Hubble 看到的是端口不匹配，先修正 toPorts；如果源身份不匹配，修正标签或命名空间；如果流量被 deny 命中，则需要调整拒绝规则本身，而不是继续堆叠 allow。这样能把“限制访问”拆成可定位的策略边界。

常见问题

只写 egress 允许，为什么 API 还是访问不了？

请求可能已经从 frontend 放行，但 api 的 ingress 仍处于默认拒绝，或者 api 侧有匹配的 deny。两端都要检查。

为什么加了策略后 DNS 也失败？

因为 egress 白名单没有自动包含 DNS。为 kube-dns 的 UDP/TCP 53 单独写出站规则，并确认 DNS Pod 的实际标签。

allow 和 deny 同时存在时看哪条？

先看 deny。Cilium 文档说明，匹配到的 deny 优先于 allow；删除或收窄 deny 后，再检查 allow 的对象、端口和协议。

小结

Cilium NetworkPolicy 限制访问的核心不是把策略改成全放行，而是把连接拆成入站、出站、身份和端口四个维度。先让选择器只命中目标 Pod，再分别给 frontend 到 api:8080、frontend 到 DNS 的必要关系写规则，最后用策略对象和 Hubble 的被拒绝流量交叉定位，通常就能找到真正缺失的边界。