Kubernetes NetworkPolicy，只允许来自同一命名空间和ALB入口的流量

Question

我试图在库伯内特斯上编写一个在AWS EKS下工作的网络策略。我想实现的是允许来自同一命名空间的pod/pod流量，并允许从AWS ALB入口转发的外部流量。

AWS ALB入口是在同一个NameSpace下创建的，所以我在想只有使用DENY来自其他命名空间的所有流量就足够了，但是当我使用来自ALB入口负载均衡器（其内部IP地址与pod/pod位于同一名称空间）的流量时是不允许的。然后，如果我添加来自外部客户端的允许流量，它允许进入，但也允许其他命名空间。

所以我的例子是这样的：（这并不像预期的那样有效）

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-from-other-namespaces
  namespace: os
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}

---

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-external
  namespace: os
spec:
  podSelector:
    matchLabels:
      app: nginx
      tier: prod
      customer: os
  ingress:
  - ports:
    - port: 80
    from: []

当使用第一个策略时，ALB入口被阻止，添加第二个策略时，也允许使用其他名称空间，这是我不想要的。我只能允许AWS ALB入口的内部IP地址，但它可以随时间变化，并且是动态创建的。

Answer 1

根据设计（Kubernetes NetworkPolicy API），如果endpoint可以从外部访问，那么为其他名称空间阻止它是没有意义的。（毕竟，它也可以通过公共LB从其他名称空间访问，因此为已经可以公开访问的endpoint设置内部防火墙是没有意义的。）早在设计这个API的时候，我就被告知这一点。

然而，您可能会发现某些CNI插件（Calico、Cilium等）提供了非标准的CRD API，这些API具有明确的“拒绝”操作，可以取代“允许”操作。它们可以解决您的问题。

最后，答案取决于CNI插件的实现，AWS如何在Kubernetes网络方面实现ALBs，以及CNI插件如何处理这一问题。除了询问CNI提供商（或他们的文档），没有简单的答案。