51CTO首页
AI.x社区
博客
学堂
精品班
软考社区
免费课
企业培训
鸿蒙开发者社区
WOT技术大会
IT证书
公众号矩阵
移动端
短视频免费课程课程排行直播课软考学堂
全部课程厂商认证IT技术24年11月软考PMP项目管理免费题库
在线学习
文章资源问答课堂专栏直播
51CTO
鸿蒙开发者社区
51CTO技术栈
51CTO官微
51CTO学堂
51CTO博客
CTO训练营
鸿蒙开发者社区订阅号
51CTO软考
51CTO学堂APP
51CTO学堂企业版APP
鸿蒙开发者社区视频号
51CTO软考题库
账号设置 退出

Kubernetes网络策略，这一篇就够了

作者：容器码头
云计算
目前许多组织都在采用Kubernetes来运行他们的应用程序。以至于有些人将Kubernetes称为新的数据中心操作系统。因此，组织开始将Kubernetes(通常缩写为k8s)视为关键任务平台，它需要包括网络安全在内的成熟业务流程。

 目前许多组织都在采用Kubernetes来运行他们的应用程序。以至于有些人将Kubernetes称为新的数据中心操作系统。因此，组织开始将Kubernetes(通常缩写为k8s)视为关键任务平台，它需要包括网络安全在内的成熟业务流程。

[[326130]]

负责保护这个新平台的网络安全团队可能发现它出奇的不同。例如，默认的Kubernetes策略是允许任何连接。

本文提供了一些关于Kubernetes网络策略工作原理的简介，它们如何与传统防火墙策略进行比较以及一些可以帮助你保护Kubernetes应用程序的陷阱和最佳实践。

Kubernetes网络策略

Kubernetes提供了一种称为网络策略的机制，可用于对部署在平台上的应用程序实施第3层分隔。网络策略缺乏现代防火墙的高级功能，如第7层控制和威胁检测，但是它们确实提供了基本的网络安全，这是一个很好的起点。

网络策略控制Pod的通信

Kubernetes的工作负载在pod中运行，pod由一个或多个部署在一起的容器组成。Kubernetes为每个pod分配一个IP地址，这个地址可以从其他所有pod路由，甚至可以跨底层服务器。Kubernets网络策略指定pod组的访问权限，类似于云服务中的安全组用于控制对虚拟机实例的访问。

编写网络策略

与其他Kubernetes资源一样，网络策略可以使用一种称为YAML的语言定义。下面是一个简单的例子，它允许从负载均衡到postgres的访问。 

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.postgres 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: postgres 
  10.   ingress: 
  11.   - from: 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: balance 
  15.   policyTypes: 
  16.   - Ingress 

  

为了编写你自己的网络策略，你需要对yaml有基本的了解。Yaml基于缩进(使用的是空格，而不是tab)。缩进项属于其上方最接近的缩进项。连字符(破折号)开始一个新的列表项。所有其他项都是映射条目。你可以在网上找到大量关于yaml的信息。

编写完策略的YAML文件后，使用kubectl创建策略： 

  1. kubectl create -f policy.yaml 

网络策略定义

网络策略定义由四个元素组成：

podSelector：将受此策略约束的pod(策略目标)。必填

policyType：指定哪些类型的策略包含在这个策略中，ingress或egress。该项是可选的，但建议总是明确的指定它。可选

ingress：允许传入目标pod的流量。可选

egress：允许从目标pod传出的流量。可选

下面这个例子是从Kubernetes官网上改编的(将“role”改为了“app”)，它指定了四个元素： 

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: test-network-policy 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: db 
  10.   policyTypes: 
  11.   - Ingress 
  12.   - Egress 
  13.   ingress: 
  14.   - from: 
  15.     - ipBlock: 
  16.         cidr: 172.17.0.0/16 
  17.         except: 
  18.         - 172.17.1.0/24 
  19.     - namespaceSelector: 
  20.         matchLabels: 
  21.           project: myproject 
  22.     - podSelector: 
  23.         matchLabels: 
  24.           role: frontend 
  25.     ports: 
  26.     - protocol: TCP 
  27.       port: 6379 
  28.   egress: 
  29.   - to: 
  30.     - ipBlock: 
  31.         cidr: 10.0.0.0/24 
  32.     ports: 
  33.     - protocol: TCP 
  34.       port: 5978 

 

 注意，你不必包含所有四个元素。podSelector是必填的，其余三个是可选的。

如果你忽略了policyType，则推断如下：

  • 策略总是被认为指定了一个ingress定义。如果你没有明确的定义它，它将被视为“不允许流量“。
  • egress将由是否存在egress元素诱导。

为了避免错误，建议总是显式的指定policyType。

如果没有提供ingress或egress的定义，并且根据上面的逻辑假定它们存在，策略将认为它们是“不允许流量”。

默认策略是允许

当没有定义任何策略时，Kubernetes允许所有通信。所有pod都可以相互自由通信。从安全角度来看，这听起来可能有悖常理，但请记住，Kubernetes是由希望应用程序进行通信的开发人员设计的。网络策略是作为后来的增强功能添加的。

命名空间

命名空间是Kubernetes的多租户机制，旨在将命名空间环境相互隔离，但是，命名空间的通信在默认情况下仍然是被允许的。

与大多数Kubernetes实体一样，网络策略也位于特定的命名空间中。元数据头部告诉Kubernetes策略属于哪个命名空间： 

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: test-network-policy 
  5.   namespace: my-namespace 
  6. spec: 
  7. ... 

如果你没有明确指定元数据的命名空间，它将应用于kubectl提供的命名空间(默认是namespace=default)。 

  1. kubectl apply -n my-namespace -f namespace.yaml 

建议显式指定命名空间，除非你正在编写的策略要统一应用在多个命名空间中。

策略中的podSelector元素将从策略所属的命名空间中选择pod(它不能从另一个命名空间选择pod)。

ingress和egress元素中的podSelector也会选择相同命名空间中的pod,除非你将它们和namespaceSelector一起使用。

策略命名约定

策略的名称在命名空间中是唯一的。一个命名空间中不能有两个同名的策略，但是不同的命名空间可以有同名的策略。当你想要在多个命名空间重复应用某个策略时，这非常方便。

我喜欢的策略命名方法之一是将命名空间与pod组合起来，例如： 

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.postgres 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: postgres 
  10.   ingress: 
  11.   - from: 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: admin 
  15.   policyTypes: 
  16.   - Ingress 

 

 

标签

Kubernetes对象，如pod和namespace，可以附加用户自定义标签。Kubernetes网络策略依赖于标签来选择它们应用于的pod：

  1. podSelector: 
  2.   matchLabels: 
  3.     role: db 

或者它们应用于的命名空间。下面的例子中选择匹配标签的命名空间中的所有pod：

  1. namespaceSelector: 
  2.   matchLabels: 
  3.     project: myproject 

需要注意的一点是：如果你使用namespaceSelector，请确保所选择的命名空间确实具有所使用的标签。请记住，像default和kube-system这样的内置命名空间没有现成的标签。你可以像这样给命名空间添加一个标签：

  1. kubectl label namespace default namespace=default 

元数据中的namespace是命名空间的实际名称，而不是标签：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: test-network-policy 
  5.   namespace: default 
  6. spec: 
  7. ... 

源和终点

防火墙策略由具有源和终点的规则组成。Kubernetes网络策略是为目标(应用策略的一组pod)定义的，然后为目标指定传入或传出流量。再次使用相同的例子，你可以看到策略目标——默认命名空间中所有具有标签为“db:app”的pod:

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: test-network-policy 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: db 
  10.   policyTypes: 
  11.   - Ingress 
  12.   - Egress 
  13.   ingress: 
  14.   - from: 
  15.     - ipBlock: 
  16.         cidr: 172.17.0.0/16 
  17.         except: 
  18.         - 172.17.1.0/24 
  19.     - namespaceSelector: 
  20.         matchLabels: 
  21.           project: myproject 
  22.     - podSelector: 
  23.         matchLabels: 
  24.           role: frontend 
  25.     ports: 
  26.     - protocol: TCP 
  27.       port: 6379 
  28.   egress: 
  29.   - to: 
  30.     - ipBlock: 
  31.         cidr: 10.0.0.0/24 
  32.     ports: 
  33.     - protocol: TCP 
  34.       port: 5978 

 

 

 

 

该策略中的ingress项允许到目标pod的传入流量。因此，ingress被解释为“源”，目标被解释为各自的“终点”。同样，egress被解释为“终点”，目标是各自的“源”。

 

 

Egress和DNS

当执行egress时，必须小心不要阻止DNS，Kubernetes使用DNS将service的名称解释为其IP地址。否则，这个策略将不起作用，因为你没有允许balance执行DNS查找：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.balance 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: balance 
  10.   egress: 
  11.   - to: 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: postgres 
  15.   policyTypes: 
  16.   - Egress 

 

 

要解决它，你必须允许访问DNS服务：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.balance 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: balance 
  10.   egress: 
  11.   - to: 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: postgres 
  15.   - to: 
  16.     ports: 
  17.     - protocol: UDP 
  18.       port: 53 
  19.   policyTypes: 
  20.   - Egress 

 

 

“to”元素为空，它隐式选择了所有命名空间中的所有pod，从而允许balance通过Kubernetes的DNS服务执行DNS查找，DNS服务通常位于kube-system命名空间中。

虽然这是有效的，但它过于宽松和不安全——它允许在集群外部进行DNS查找。

你可以分阶段锁定它：

1.通过添加一个namespaceSelector只允许在集群内进行DNS查找：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.balance 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: balance 
  10.   egress: 
  11.   - to: 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: postgres 
  15.   - to: 
  16.     - namespaceSelector: {} 
  17.     ports: 
  18.     - protocol: UDP 
  19.       port: 53 
  20.   policyTypes: 
  21.   - Egress 

 

 

2.只允许DNS在kube-system命名空间中

为此，你需要为kube-system命名空间添加一个标签：

  1. kubectl label namespace kube-system namespace=kube-system 

然后用namespaceSelector在策略中指定它：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.balance 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: balance 
  10.   egress: 
  11.   - to: 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: postgres 
  15.   - to: 
  16.     - namespaceSelector: 
  17.         matchLabels: 
  18.           namespace: kube-system 
  19.     ports: 
  20.     - protocol: UDP 
  21.       port: 53 
  22.   policyTypes: 
  23.   - Egress 

 

 

3.偏执狂可能想更进一步，将DNS限制为kube-system命名空间中特定的DNS服务。请参考下面的“通过命名空间和pod过滤”章节。

另一种选择是在命名空间级别允许DNS，这样就不需要为每个服务指定它了：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.dns 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: {} 
  8.   egress: 
  9.   - to: 
  10.     - namespaceSelector: {} 
  11.     ports: 
  12.     - protocol: UDP 
  13.       port: 53 
  14.   policyTypes: 
  15.   - Egress 

空的podSelector选择该命名空间中的所有pod。

 

 

第一个匹配和规则顺序

防火墙管理员知道对数据包采取的操作(允许或拒绝)由与其匹配的第一个规则决定。但是在Kubernetes中，策略的顺序并不重要。默认的行为是，当没有定义策略时，允许所有通信，因此所有pod之间可以彼此通信。一旦定义了策略，每个至少被一个策略选择的pod，将根据选择它的策略的并集(逻辑或)进行隔离：

 

 

没有被任何策略选中的pod继续保持开放。你可以通过定义cleanup规则来改变这个行为。

Cleanup规则(拒绝)

防火墙策略通常通过any-any-any-deny规则来丢弃所有非显式允许的流量。Kubernetes没有拒绝操作，但是你可以使用一个常规的规则来实现相同的效果，该策略指定policyTypes=Ingress，但是省略了实际ingress的定义，这被解释为“不允许进入”。

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: deny-all 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: {} 
  8.   policyTypes: 
  9.   - Ingress 

 

 

该策略选择命名空间中的所有pod作为源，未定义ingress——这意味着不允许流量进入。

类似的，你可以拒绝来自一个命名空间的所有出站流量：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: deny-all-egress 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: {} 
  8.   policyTypes: 
  9.   - Egress 

 

 

请记住，任何其他允许访问命名空间中pod的策略都将优先于此拒绝策略——相当于防火墙中将允许策略添加到拒绝策略之上。

Any-Any-Any-Allow

通过使用一个空的ingress元素修改上面的deny-all策略，可以创建一个allow-all策略：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: allow-all 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: {} 
  8.   ingress:  
  9.   - {} 
  10.   policyTypes: 
  11.   - Ingress 

 

 

这允许所有命名空间中的所有pod(和IP)到默认命名空间中的任何pod的通信。这是默认行为，因此通常不需要这么做。但是，为了查找问题，暂时覆盖所有其他规则可能很有用。

你可以缩小此范围，仅允许访问默认命名空间中的一组特定的pod：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: allow-all-to-balance 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: balance 
  10.   ingress:  
  11.   - {} 
  12.   policyTypes: 
  13.   - Ingress 

 

 

下面的策略允许任何入站和出站流量(包括访问集群外的任何IP)：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: allow-all 
  5. spec: 
  6.   podSelector: {} 
  7.   ingress: 
  8.   - {} 
  9.   egress: 
  10.   - {} 
  11.   policyTypes: 
  12.   - Ingress 
  13.   - Egress 

 

 

 

 

组合多个策略

策略在三个级别上使用逻辑或进行组合。每个pod根据应用于它的所有策略的并集决定是否允许通信。

1.在“from”和“to”项中，你可以定义三种类型的项，他们通过“或”进行组合：

  • namespaceSelector——选择一整个命名空间
  • podSelector——选择pod
  • ipBlock——选择一个子网

你可以在from/to下定义任意数量的项(即使是相同类型也可以定义多条)，它们将通过逻辑或组合在一起：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.postgres 
  5.   namespace: default 
  6. spec: 
  7.   ingress: 
  8.   - from: 
  9.     - podSelector: 
  10.         matchLabels: 
  11.           app: indexer 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: admin 
  15.   podSelector: 
  16.     matchLabels: 
  17.       app: postgres 
  18.   policyTypes: 
  19.   - Ingress 

 

 

2.在一个策略中，ingress策略可以有多个“from”项，它们通过逻辑或组合在一起。同样，egress策略可以有多个“to”项，它们也通过逻辑或组合在一起：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.postgres 
  5.   namespace: default 
  6. spec: 
  7.   ingress: 
  8.   - from: 
  9.     - podSelector: 
  10.         matchLabels: 
  11.           app: indexer 
  12.   - from: 
  13.     - podSelector: 
  14.         matchLabels: 
  15.           app: admin 
  16.   podSelector: 
  17.     matchLabels: 
  18.       app: postgres 
  19.   policyTypes: 
  20.   - Ingress 

 

 

3.多个策略也通过逻辑或组合在一起。

但是当组合策略时，这里有一些限制:Kubernetes只能组合policyType(ingress或egress)不同的策略，多个策略都指定ingress(或egress)将会互相覆盖。

命名空间之间的通信

默认情况下，命名空间间的通信是允许的。你可以使用deny-all策略来改变它，以阻止从或者到该命名空间的通信。

如果你阻止了对某个命名空间的访问，可以使用namespaceSelector允许来自一个特定的命名空间的访问。

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: database.postgres 
  5.   namespace: database 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: postgres 
  10.   ingress: 
  11.   - from: 
  12.     - namespaceSelector: 
  13.         matchLabels: 
  14.           namespace: default 
  15.   policyTypes: 
  16.   - Ingress 

 

 

这允许default命名空间中的所有pod访问database命名空间中的postgres pod。但是，如果只想允许default命名空间中特定的pod访问postgres该怎么办呢?

通过namespace和pod联合过滤

Kubernetes 1.11及以上允许你将namespaceSelector和podSelector通过逻辑与组合在一起：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: database.postgres 
  5.   namespace: database 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: postgres 
  10.   ingress: 
  11.   - from: 
  12.     - namespaceSelector: 
  13.         matchLabels: 
  14.           namespace: default 
  15.       podSelector: 
  16.         matchLabels: 
  17.           app: admin 
  18.   policyTypes: 
  19.   - Ingress 

 

 

为什么这被解释为“与”，而不是“或”呢?

请注意，podSelector不是以破折号开头的，在yaml中这意味着，podSelector与前面的namespaceSelector属于同一个列表项，因此它们通过逻辑与进行组合。如果你在podSelector前面添加一个破折号，将创建一个新的列表项，这将与前面的namespaceSelector通过逻辑或组合。要在所有命名空间中选择具有特定标签的pod，可以指定一个空的namespaceSelector：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: database.postgres 
  5.   namespace: database 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: postgres 
  10.   ingress: 
  11.   - from: 
  12.     - namespaceSelector: {} 
  13.       podSelector: 
  14.         matchLabels: 
  15.           app: admin 
  16.   policyTypes: 
  17.   - Ingress 

 

 

多个标签通过逻辑与组合

具有多个对象(主机、网络、组...)的防火墙规则被解释为逻辑或。例如，如果数据包的源匹配HOST_1或HOST_2，则应用此规则：

 

 

与之相反的是，在Kubernetes中，podSelector和namespaceSelector中的多个标签通过逻辑与进行组合。例如，这将选择同时具有标签role=db和version=v2的pod：

  1. podSelector: 
  2.   matchLabels: 
  3.     role: db 
  4.     version: v2 

相同的逻辑适用所有类型的选择器：策略目标的选择器、pod的选择器、命名空间的选择器。

子网和IP地址(ipBlock)

防火墙使用vlan、ip和子网来分割网络。在Kubernetes中，pod的IP是自动分配的，并且可能经常变动，因此网络策略使用标签来选择pod和命名空间。子网(ipBlock)用于ingress或egress连接(南北向)。例如，下面这个策略允许default命名空间中的所有pod访问谷歌的DNS服务：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: egress-dns 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: {} 
  8.   policyTypes: 
  9.   - Egress 
  10.   egress: 
  11.   - to: 
  12.     - ipBlock: 
  13.         cidr: 8.8.8.8/32 
  14.     ports: 
  15.     - protocol: UDP 
  16.       port: 53 

 

 

本例中空的podSelector表示“选择该命名空间中的所有pod”。该策略只允许访问8.8.8.8，这意味着它拒绝访问其他任何IP。因此，实际上，你已经阻止了对Kubernetes内部DNS服务的访问。如果你仍然想允许它，需要显式的指定它。

通常ipBlock和podSelector是互斥的，因为通常你在ipBlock中不使用内部pod IP。如果你使用内部pod IP指定ipBlock，它实际上将允许与具有这些ip的pod进行通信。但是在实践中并不知道该用哪些IP，这就是为什么不应该用IP来选择pod。

下面这个策略中包含所有IP，并允许访问所有其它pod：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: egress-any 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: {} 
  8.   policyTypes: 
  9.   - Egress 
  10.   egress: 
  11.   - to: 
  12.     - ipBlock: 
  13.         cidr: 0.0.0.0/0 

 

 

你可以通过排除内部IP来只允许访问外部IP。例如，如果pod的子网是10.16.0.0/14：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: egress-any 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: {} 
  8.   policyTypes: 
  9.   - Egress 
  10.   egress: 
  11.   - to: 
  12.     - ipBlock: 
  13.         cidr: 0.0.0.0/0 
  14.         except: 
  15.         - 10.16.0.0/14 

 

 

 

端口和协议

pod通常只监听一个端口，这意味着你可以简单的在策略中省略端口，默认允许任何端口。但是最好将策略设置为受限的，显式的指定端口：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.postgres 
  5.   namespace: default 
  6. spec: 
  7.   ingress: 
  8.   - from: 
  9.     - podSelector: 
  10.         matchLabels: 
  11.           app: indexer 
  12.     - podSelector: 
  13.         matchLabels: 
  14.           app: admin 
  15.     ports: 
  16.       - port: 443 
  17.         protocol: TCP 
  18.       - port: 80 
  19.         protocol: TCP 
  20.   podSelector: 
  21.     matchLabels: 
  22.       app: postgres 
  23.   policyTypes: 
  24.   - Ingress 

 

 

请注意，端口应用于它们所在的“to”或“from”子句中的所有项。如果你想为不同的项指定不同的端口，你可以将ingress或egress拆分为多个“to”或“from”，每个都有自己的端口：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.postgres 
  5.   namespace: default 
  6. spec: 
  7.   ingress: 
  8.   - from: 
  9.     - podSelector: 
  10.         matchLabels: 
  11.           app: indexer 
  12.     ports: 
  13.      - port: 443 
  14.        protocol: TCP 
  15.   - from: 
  16.     - podSelector: 
  17.         matchLabels: 
  18.           app: admin 
  19.     ports: 
  20.      - port: 80 
  21.        protocol: TCP 
  22.   podSelector: 
  23.     matchLabels: 
  24.       app: postgres 
  25.   policyTypes: 
  26.   - Ingress 

 

 

端口的默认行为：

  • 如果完全省略端口，则表示所有端口和所有协议
  • 如果省略协议，则默认为TCP
  • 如果省略端口，则默认为所有端口

最佳实践：不要依赖默认行为，显式的指明。

注意你必须使用pod的端口，而不是service的端口。

策略是为pod定义的还是为service定义的?

当一个pod访问Kubernetes中另一个pod时，它通常要通过service，service是一个虚拟的负载均衡器，它将流量转发到实现该服务的pod上。你可能会以为网络策略是控制对service的访问的，但事实并非如此。Kubernetes网络策略是应用于pod的端口，而非service的端口。

例如，如果一个service监听80端口，但是它将流量转发到监听8080端口的pod上，你需要在网络策略中指定8080端口。

这种设计不是最优的，因为当有人更改服务的内部工作方式时(如pod正在监听的端口)，你需要更新网络策略。

显然，有一种解决方案可以解决这个问题，即使用命名端口，而不是硬编码的数字端口：

  1. apiVersion: networking.k8s.io/v1 
  2. kind: NetworkPolicy 
  3. metadata: 
  4.   name: default.allow-hello 
  5.   namespace: default 
  6. spec: 
  7.   podSelector: 
  8.     matchLabels: 
  9.       app: hello 
  10.   policyTypes: 
  11.   - Ingress 
  12.   ingress: 
  13.   - from: 
  14.     - podSelector: 
  15.         matchLabels: 
  16.           run: curl 
  17.     ports: 
  18.     - port: my-http 

你需要在pod的定义中指定这个端口的名字：

  1. apiVersion: extensions/v1beta1 
  2. kind: Deployment 
  3. metadata: 
  4.   labels: 
  5.     app: hello 
  6.   name: hello 
  7. spec: 
  8.   selector: 
  9.     matchLabels: 
  10.       app: hello 
  11.   template: 
  12.     metadata: 
  13.       labels: 
  14.         app: hello 
  15.     spec: 
  16.       containers: 
  17.       - image: gcr.io/hello-minikube-zero-install/hello-node 
  18.         imagePullPolicy: Always 
  19.         name: hello-node 
  20.         ports: 
  21.         - containerPort: 8080 
  22.           name: my-http 

这样就将网络策略和pod解耦了。

Ingress

术语“ingress”在Kubernetes中有两种含义：

  1. ingress网络策略允许你控制其他pod或外部IP对pod的访问
  2. Kubergess的ingress是一种配置外部负载均衡器路由流量到集群内部的方式

你可以编写一个k8s网络策略限制来自Kubernetes ingress的访问，但在大多数情况下这不是很有用，因为它只控制负载均衡器的内部IP。为了控制可以访问集群的外部子网，你需要在外部实施点(如负载均衡本身或负载均衡前面的防火墙)配置访问控制。

需要同时定义ingress和egress么?

简单的回答是肯定的——为了允许pod A访问pod B，你需要允许pod A通过egress策略创建出站连接，并允许pod B通过ingress策略接受入站连接。

然而，实际上，你可能对两个方向中的一个使用默认的允许策略。

如果源pod被一个或多个egress策略选中，则将根据策略联合对其进行限制，在这种情况下你需要明确允许它连接到目标pod。如果pod不被任何策略选中，则它默认允许所有的出站流量。

同样，被一个或多个ingress策略选中的目标pod，也会受到策略的联合限制，在这种情况下你必须明确允许它接受来自源pod的流量。如果pod没有被任何策略选中，则它默认允许所有入站流量。

hostNetwork陷阱

Kubernetes通常在自己的隔离网络中运行pod，然而，你可以指定Kubernetes在主机上运行pod：

  1. hostNetwork: true 

这样会完全绕开网路策略，pod像主机上运行的其他任何进程一样进行通信。

流量日志

Kubernetes网络策略不能生成流量日志。这很难知道策略是不是像预期一样工作。这也是安全分析方面的主要限制。

控制到外部服务的流量

Kubernetes网络策略不允许你为egress指定完全限定的域名(DNS)。当试图控制到无固定IP的外部站点(如aws.com)的流量时，这是一个限制。

策略验证

防火墙将警告甚至拒绝接受无效的策略。Kubernetes也做了一些验证。当使用kubectl定义网络策略时，Kubernetes可能会告诉你策略无效并且拒绝接受。在其它情况下，Kubernetes将接受策略并修改它缺失的细节，你可以通过以下命令查看它：

kubernetes get networkpolicy  -o yaml

请注意，Kubernetes的验证不是无懈可击的，它可能允许策略中出现某些类型的错误。

执行

Kubernetes本身并不执行网络策略，它只是一个API网关，它将执行的艰巨工作传递给一个称为容器网络接口(CNI)的底层系统。在没有合适CNI的Kubernetes集群中定义策略就像在没有安装防火墙的服务器上定义防火墙规则一样。你必须确保拥有具有安全功能的CNI，或者，对于托管的Kubernetes平台，你需要显式的启用将为你安装CNI的网络策略。

请注意，如果CNI不支持，你定义了一个网络策略，Kubernetes不会向你告警。

有状态还是无状态?

目前所有的Kubernetes CNI都是有状态的，这使得pod能在它发起的TCP连接上接收应答，而不必为应答打开高端口。我不知道有没有Kubernetes标准保证状态性。

高级安全策略管理

以下是一些针对Kubernetes实施更高级的网络策略的方法：

  1. 服务网格设计模式使用sidecar在服务级别提供更高级的遥测和流量控制。有关示例，请参考Istio。
  2. 一些CNI提供商已经将他们的工具扩展到了Kubernetes网络策略之外。
  3. Tufin Orca——用于实现Kubernetes网络策略的可视化和自动化。

总结

Kubernetes网络策略为集群划分提供了一种很好的方法，但是它们不直观并且有许多注意的地方。我相信，由于这种复杂性，一定有许多集群在他们的策略中存在“bug”。可能的解决方案是自动化策略定义或其他分割方法。同时，希望本文对澄清和解决你可能遇到的问题有所帮助。

 

责任编辑：武晓燕 来源： 今日头条
Kubernetes网络策略DNS
相关推荐
Redis内存淘汰策略，看这一篇就够了！
Redis作为当前最常用的开源内存数据库，性能十分高，据官方数据表示Redis读的速度是110000次s,写的速度是81000次s。而且Redis支持数据持久化，众多数据结构存储，masterslave模式数据备份等多种功能。

2019-04-10 10:43:15

Redis内存淘汰策略
前端登录，这一篇就够了
登录是每个网站中都经常用到的一个功能，在页面上我们输入账号密码，敲一下回车键，就登录了，但这背后的登录原理你是否清楚呢？今天我们就来介绍几种常用的登录方式。

2020-08-03 10:00:11

前端登录服务器
精通ES，这一篇就够了
本文图片大多来自官网，其余为作者作图。ES的官网其实介绍的很详细，但是很少人将它整理出来。我这里整理了出来，并加上了自己的看法，希望可以和大家一起深入学习ES。

2023-04-24 08:00:00

ES集群容器
Kubernetes 集群网络从懵圈到熟悉，看这一篇就够了
在Kubernetes中要保证容器之间网络互通，网络至关重要。

2021-04-14 15:54:20

Kubernetes程序工具
初识Redis，看这一篇就够了
Redis（全称：RemoteDictionaryServer远程字典服务）是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、KeyValue数据库。

2020-02-18 16:20:03

Redis ANSI C语言日志型
HTTP缓存看这一篇就够了
通过前文，我们了解到HTTP缓存主要分：强制缓存、协商缓存。强制缓存由Exipres（HTTP1.0）、CacheControl（HTTP1.1）控制。客户端直接读本地缓存，不会再跟服务器端交互，状态码200。

2023-02-10 09:04:27

学习 Git，看这一篇就够了！
GitLens是一个VSCode插件，可以用来查看项目的提交记录、文件修改记录、显示每行代码的提交记录等。通过丰富的可视化和强大的比较命令获得有价值的见解。

2022-06-20 09:01:23

Git插件项目
搞懂限流算法这一篇就够了
大家都知道，对于高并发的业务场景，我们为了保障服务的稳定，经常会祭出三大利器：缓存、熔断降级和服务限流。

2019-08-13 15:36:57

限流算法令牌桶
用户分析，看这一篇就够了
简单的拉个交叉表，丫就不叫分析，丫就是一张表而已。做数据分析，要有清晰的目标和可落地的细节才行。在用户分析领域，则是分成了策略执行两大类专题。

2022-08-01 11:33:09

用户分析标签策略
学习队列，看这一篇就够了！
本文主要介绍队列的结构、基本原理及操作，涉及到两种实现：顺序队列和链队列。

2021-04-08 07:37:39

队列数据结构算法
OpenTelemetry入门看这一篇就够了
分布式跟踪可以帮助查看整个请求过程中服务之间的交互，并可以让我们深入了解系统中请求的整个生命周期。它帮助我们发现应用程序中的错误、瓶颈和性能问题。OpenTelemetry可以用于从应用程序收集数据。它是一组工具、API和SDK集合，我们可以使用它们来检测、生成、收集和导出遥测数据（指标、日志和追踪），以帮助分析应用的性能和行为。

2023-09-11 08:13:03

分布式跟踪工具
干货 | 卷积神经网络入门这一篇就够了
卷积神经网络是近年发展起来，并引起广泛重视的一种高效识别方法。20世纪60年代，Hubel和Wiesel在研究猫脑皮层中用于局部敏感和方向选择的神经元时发现其独特的网络结构可以有效地降低反馈神经网络的复杂性，继而提出了卷积神经网络（ConvolutionalNeuralNetworks简称CNN）。

2018-01-17 09:32:45

人工智能卷积神经网络CNN
Python操作MongoDB看这一篇就够了
MongoDB是由C++语言编写的非关系型数据库，是一个基于分布式文件存储的开源数据库系统，其内容存储形式类似JSON对象，它的字段值可以包含其他文档、数组及文档数组，非常灵活。在这一节中，我们就来看看Python3下MongoDB的存储操作。

2018-05-22 08:24:50

PythonPyMongoMongoDB
Java中的String，这一篇就够了
当字符串是不可变时，字符串常量池才有意义。字符串常量池的出现，可以减少创建相同字面量的字符串，让不同的引用指向池中同一个字符串，为运行时节约很多的堆内存。若字符串可变，字符串常量池失去意义，基于常量池的String.intern()方法也失效，每次创建新的String将在堆内开辟出新的空间，占据更多的内存。

2024-04-08 10:01:33

消息队列选型看这一篇就够了
本文是关于消息队列（MQ）选型和常见问题的精心整理。在这篇文章中，我们将详细介绍消息队列的概念、作用以及如何选择适合自己需求的消息队列系统。

2024-09-23 08:00:00

消息队列MQ分布式系统
小白入门大数据，这一篇就够了
大数据这个行业也是一样，好像这个互联网时代，不知道大数据就落伍了一样，但很多一部分人也只限于了解了大数据这个词，并加上自己想象的定义。

2021-05-14 23:31:50

大数据计算机开发
Java 集合框架看这一篇就够了
关于Map，之前那篇HashMap的文章已经讲的非常透彻详尽了，所以本文不再赘述。如果还没看过那篇文章的小伙伴，快去公众号内回复「HashMap」看文章吧～

2020-07-03 08:21:57

Java集合框架
架构整洁之道，看这一篇就够了！
本篇文章我们将从软件系统的价值出发，首先认识架构工作的价值和目标，接下来依次了解架构设计的基础、指导思想(设计原则)、组件拆分的方法和粒度、组件之间依赖设计、组件边界多种解耦方式以及取舍、降低组件之间通信成本的方法，从而最终指导我们做出正确的架构决策和架构设计。

2019-05-14 09:31:16

架构整洁软件编程范式
看这一篇就够了
不管是API的设计还是代码架构的设计，原则其实都差不多，要能够松耦合、易扩展、在满足现有需求的基础上，再多往前想一步，避免过度设计。

2023-10-17 08:15:28

API前后端分离
全面解析｜搞懂Nginx这一篇就够了
Nginx是一个http服务器，是一个使用c语言开发的高性能的http服务器及反向代理服务器。Nginx是一款高性能的http服务器反向代理服务器及电子邮件(IMAPPOP3)代理服务器。由俄罗斯的程序设计师IgorSysoev所开发，官方测试Nginx能够支撑5万并发链接，并且cpu、内存等资源消耗却非常低，运行非常稳定。本文将为大家详细介绍关于Nginx的原理以及在应用场景下的相关解析。

2020-11-06 10:01:06

Nginx
点赞
收藏

51CTO技术栈公众号

业务
速览
在线客服