k8s的networkpolicy

Network Policy

pod之间的通信默认是不隔离的，他们之是能相互通信的，但如果你想通过IP地址或者端口来管理网络通信，那么就可以使用k8s的networkpolicy功能。该功能是一个以应用程序为中心的构造，允许你通过各种各样的网络entities来指定什么样的pod允许通信。
Pod可以与之通信的entities通过以下3个标识符的组合来识别:

允许通信的其他pods(例外：pod不能阻止对自身的访问)
允许通过的namespaces
IP blocks((例外:始终允许与运行Pod的节点之间的通信，而不管Pod或节点的IP地址)
当定义一个基于pod或者基于namespace的NetworkPolicy是，你可以使用selector来指定允许to和From两个方向的pod通信。同时，在创建基于IP的NetworkPolicy是，我们定义基于IPblock的策略。

前提

NetworkPolicy是由网络插件实现的。要使用NetworkPolicy那么你必须先使用支持NetworkPolicy的网络插件，例如：Calico、Canal、Cilium、Contiv和Weave等等。

NetworkPolicy资源

如下是一个NetworkPolicy资源的例子：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: net
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

必备字段:像其他Kubernetes配置一样，一个NetworkPolicy必备的字段有apiVersion, kind, and metadata.
spec:NetworkPolicy spec 拥有在给定名称空间中定义特定网络策略所需的所有信息。
namespace:注意这里的networkpolicy只对本域名内的资源生效。
podSelector:每个NetworkPolicy都包含一个podSelector，它选择策略应用到的pods分组。示例策略选择标签为“role=db”的pods也就是说这个NetworkPolicy应用到标签为role=db的pod中，NetworkPolicy对没有这个标签的pod不生效。一个空的podSelector选择名称空间中的所有pods。若果为{}表示所有pod.
policyTypes:每个NetworkPolicy都包含一个policyTypes列表，其中可以包含入口Ingress、出口Egress，也可以同时包含入口和出口。policyTypes字段指示给定的策略是否应用于将流量输入到选定的pod、将流量从选定的pod输出或同时应用于两者。如果在NetworkPolicy上没有指定策略类型，那么默认情况下将始终设置Ingress，如果NetworkPolicy有任何出口规则，则将具体设置Egress规则。
ingress:每个NetworkPolicy可能包括一个允许进入规则的列表。每个规则都允许匹配from和ports字段的流量。示例策略包含一个规则，它匹配来自三个源之一的单个端口上的流量，第一个通过ipBlock指定，第二个通过namespaceSelector指定，第三个通过podSelector指定。如果值为{}，表示默认允许所有ingress流量；如果没有值表示不允许任何ingress流量。
egress:每个网络策略包括一张允许出口规则的列表。每个规则都允许匹配to和ports字段的流量。示例策略包含一个规则，它将单个端口上的流量匹配到10.0.0.0/24中的任何目的地。如果值为{}，表示默认允许所有egress流量；如果没有值表示不允许任何egress流量。
所以，例子中的NetworkPolicy的规则解读如下：

在default namespace中隔离“role=db”进出流量(如果它们还没有被隔离)
(Ingress规则)允许连接到TCP端口6379上的标签为“role=db”的default namespace中的所有pods:
- 在“default namespace中，标签为“role=frontend”的任何pod
- 在名称空间中标签为“project=myproject”的任何pod
- IP地址在172.17.0.0-172.17.0.255和172.17.2.0-172.17.255.255之间的
(Egress规则)允许从标签为“role=db”的default namespace中的任何pod连接到TCP端口5978上的CIDR 10.0.0.0/24

你不能用networkPolicy做的事情

在Kubernetes1.20版本中，NetworkPolicy API中不存在以下功能，但是您可以使用操作系统组件(如SELinux、OpenVSwitch、IPTables等)或第7层技术(入口控制器、服务网格实现)或许可控制器来实现变通方法。如果您是Kubernetes中的网络安全新手，那么值得注意的是，以下用户场景(还)不能使用NetworkPolicy API实现。在NetworkPolicy API的未来版本中，正在积极讨论其中一些feature.

强制内部集群通信量通过公共网关(最好使用服务网格或其他代理)。
任何与TLS相关的东西(可以使用服务网格或ingress控制器实现此功能)
特定于节点的策略(可以使用CIDR表示法，但是不能通过特定的Kubernetes标识来指定节点)
以名称作为命名空间或服务的目标(但是，您可以通过它们的标签来定位pods或命名空间，这通常是一种可行的解决方案)。
创建或管理由第三方完成的“策略请求”。
适用于所有名称空间或pods的默认策略(有一些第三方Kubernetes发行版和项目可以做到这一点)。
高级策略查询和可达性工具。
在单个策略声明中指定端口范围的能力
记录网络安全事件(例如被阻塞或接受的连接)的能力。
显式拒绝策略的能力(目前networkpolicy的模型在默认情况下被拒绝，只有添加允许规则的能力)。
阻止环回或进入主机流量的能力(Pods当前不能阻止本地主机访问，也不能阻止来自其驻留节点的访问)。