Kubernetes 网络策略基础 | Linux 中国

导读：在你通过 Kubernetes 部署一个应用之前，了解 Kubernetes 的网络策略是一个基本的要求。

本文字数：4780，阅读时长大约： 6分钟

https://linux.cn/article-14005-1.html
作者：Mike Calizo
译者：perfiffer

随着越来越多的云原生应用程序通过 Kubernetes 部署到生产环境，安全性是你必须在早期就需要考虑的一个重要检查项。在设计云原生应用程序时，预先嵌入安全策略非常重要。不这样做会导致后续的安全问题，从而导致项目延迟，并最终给你带来不必要的压力和金钱投入。

这么多年来，人们总是把安全留到最后，直到他们的部署即将发布到生产环境时才考虑安全。这种做法会导致项目交付的延迟，因为每个组织都有要遵守的安全标准，这些规定被绕过或不遵守，并承受大量的风险才得以实现可交付成果。

对于刚开始学习 Kubernetes 实施的人来说，理解 Kubernetes 网络策略(NetworkPolicy) 可能会令人生畏。但这是在将应用程序部署到 Kubernetes 集群之前必须了解的基本要求之一。在学习 Kubernetes 和云原生应用程序时，请把“不要把安全抛在脑后！”定为你的口号。

网络策略概念

kubernetes.io(NetworkPolicy) 取代了你所知道的数据中心环境中的防火墙设备 —— 如吊舱(Pod)之于计算实例、网络插件之于路由器和交换机，以及卷之于存储区域网络（SAN）。

默认情况下，Kubernetes 网络策略允许 kubernetes.io(Pod) 从任何地方接收流量。如果你不担心吊舱的安全性，那么这可能没问题。但是，如果你正在运行关键工作负载，则需要保护吊舱。控制集群内的流量（包括入口和出口流量），可以通过网络策略来实现。

要启用网络策略，你需要一个支持网络策略的网络插件。否则，你应用的任何规则都将变得毫无用处。

kubernetes.io 上列出了不同的网络插件：

◈ CNI 插件：遵循 github.com(Container Network Interface)（CNI）规范，旨在实现互操作性。

◈ Kubernetes 遵循 CNI 规范的 github.com 版本。

◈ Kubernetes 插件：使用桥接器和主机本地 CNI 插件实现基本的 cbr0。

应用网络策略

要应用网络策略，你需要一个工作中的 Kubernetes 集群，并有支持网络策略的网络插件。

但首先，你需要了解如何在 Kubernetes 的环境使用网络策略。Kubernetes 网络策略允许 kubernetes.io 从任何地方接收流量。这并不是理想情况。为了吊舱安全，你必须了解吊舱是可以在 Kubernetes 架构内进行通信的端点。

1、使用 podSelector 进行吊舱间的通信：

1. - namespaceSelector:

2. matchLabels:

3. project: myproject

2、使用 namespaceSelector 和/或 podSelector 和 namespaceSelector 的组合进行命名空间之间的通信和命名空间到吊舱的通信。：

1. - namespaceSelector:

2. matchLabels:

3. project: myproject

4. - podSelector:

5. matchLabels:

6. role: frontend

3、对于吊舱的 IP 块通信，使用 ipBlock 定义哪些 IP CIDR 块决定源和目的。

1. - ipBlock:

2. cidr: 172.17.0.0/16

3. except:

4. - 172.17.1.0/24

注意吊舱、命名空间和基于 IP 的策略之间的区别。对于基于吊舱和命名空间的网络策略，使用选择器来控制流量，而对基于 IP 的网络策略，使用 IP 块（CIDR 范围）来定义控制。

把它们放在一起，一个网络策略应如下所示：

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: backend

10. policyTypes:

11. - Ingress

12. - Egress

13. ingress:

14. - from:

15. - ipBlock:

16. cidr: 172.17.0.0/16

17. except:

18. - 192.168.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

参考上面的网络策略，请注意 spec 部分。在此部分下，带有标签 app=backend 的 podSelector 是我们的网络策略的目标。简而言之，网络策略保护给定命名空间内称为 backend 的应用程序。

此部分也有 policyTypes 定义。此字段指示给定策略是否适用于选定吊舱的入口流量、选定吊舱的出口流量，或两者皆有。

1. spec:

2. podSelector:

3. matchLabels:

4. app: backend

5. policyTypes:

6. - Ingress

7. - Egress

现在，请看 Ingress（入口）和 Egress（出口）部分。该定义规定了网络策略的控制。

首先，检查 ingress from 部分。

此实例中，网络策略允许从以下位置进行吊舱连接：

◈ ipBlock

◈ 允许 172.17.0.0/16

◈ 拒绝 192.168.1.0/24

◈ namespaceSelector

◈ myproject: 允许来自此命名空间并具有相同标签 project=myproject 的所有吊舱。

◈ podSelector

◈ frontend: 允许与标签 role=frontend 匹配的吊舱。

1. ingress:

2. - from:

3. - ipBlock:

4. cidr: 172.17.0.0/16

5. except:

6. - 192.168.1.0/24

7. - namespaceSelector:

8. matchLabels:

9. project: myproject

10. - podSelector:

11. matchLabels:

12. role: frontend

现在，检查 egress to 部分。这决定了从吊舱出去的连接：

◈ ipBlock

◈ 10.0.0.0/24: 允许连接到此 CIDR

◈ Ports: 允许使用 TCP 和端口 5978 进行连接

1. egress:

2. - to:

3. - ipBlock:

4. cidr: 10.0.0.0/24

5. ports:

6. - protocol: TCP

7. port: 5978

网络策略的限制

仅靠网络策略无法完全保护你的 Kubernetes 集群。你可以使用操作系统组件或 7 层网络技术来克服已知限制。你需要记住，网络策略只能解决 IP 地址和端口级别的安全问题 —— 即开放系统互联（OSI）中的第 3 层或第 4 层。

为了解决网络策略无法处理的安全要求，你需要使用其它安全解决方案。以下是你需要知道的一些 kubernetes.io，在这些用例中，网络策略需要其他技术的增强。

总结

了解 Kubernetes 的网络策略很重要，因为它是实现（但不是替代）你通常在数据中心设置中使用的防火墙角色的一种方式，但适用于 Kubernetes。将此视为容器安全的第一层，仅仅依靠网络策略并不是一个完整的安全解决方案。

网络策略使用选择器和标签在吊舱和命名空间上实现安全性。此外，网络策略还可以通过 IP 范围实施安全性。

充分理解网络策略是在 Kubernetes 环境中安全采用容器化的一项重要技能。

via:

作者： 选题： 译者： 校对：

本文由 原创编译， 荣誉推出

欢迎遵照 CC-BY-NC-SA 协议规定转载，

如需转载，请在文章下留言 “ 转载：公众号名称”，

我们将为您添加白名单，授权“ 转载文章时可以修改”。