document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-22 23:00:57 +08:00
Code Issues Packages Projects Releases Wiki Activity

translated by perfiffer

Browse Source
This commit is contained in:
perfiffer 2021-11-20 21:53:50 +08:00
parent 235854017b
commit 4da8b463aa
2 changed files with 203 additions and 214 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

214
sources/tech/20211021 What you need to know about Kubernetes NetworkPolicy.md
View File

@ -1,214 +0,0 @@
[#]: subject: "What you need to know about Kubernetes NetworkPolicy"
[#]: via: "https://opensource.com/article/21/10/kubernetes-networkpolicy"
[#]: author: "Mike Calizo https://opensource.com/users/mcalizo"
[#]: collector: "lujun9972"
[#]: translator: "perfiffer"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
What you need to know about Kubernetes NetworkPolicy
======
Understanding Kubernetes NetworkPolicy is one of the fundamental
requirements to learn before deploying an application to Kubernetes.
![Parts, modules, containers for software][1]
With a growing number of cloud-native applications going to production through Kubernetes adoption, security is an important checkpoint that you must consider early in the process. When designing a cloud-native application, it is very important to embed a security strategy up front. Failure to do so leads to lingering security issues that can cause project delays and ultimately cost you unnecessary stress and money.
For years, people left security at the end—until their deployment was about to go into production. That practice causes delays on deliverables because each organization has security standards to adhere to, which are either bypassed or not followed with a lot of accepted risks to make the deliverables.
Understanding Kubernetes NetworkPolicy can be daunting for people just starting to learn the ins and outs of Kubernetes implementation. But this is one of the fundamental requirements that you must learn before deploying an application to your Kubernetes cluster. When learning Kubernetes and cloud-native application patterns, make your slogan "Don't leave security behind!"
### The NetworkPolicy concept
[NetworkPolicy][2] replaces firewall appliances in the data center context that you know—as pods to compute instances, network plugins to router and switches, and volumes to storage area network (SAN).
By default, the Kubernetes NetworkPolicy allows [pods][3] to receive traffic from anywhere. If you are not concerned about security for your pods, then that might be OK. But if you are running a critical workload, then you need to secure your pods. The way to control the traffic flow within the cluster (including ingress and egress traffic) is through NetworkPolicies.
To enable NetworkPolicy, you need a [network plugin][4] that supports NetworkPolicy. Otherwise, any rules you applied become useless.
There a different network plugins [listed on Kubernetes.io][4]:
* CNI plugins: adhere to the [Container Network Interface][5] (CNI) specification, designed for interoperability.
* Kubernetes follows the [v0.4.0][6] release of the CNI specification.
* Kubernetes plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins.
### Applying a network policy
To apply a network policy, you need a working Kubernetes cluster with a network plugin that supports NetworkPolicy.
But first, you need to understand how to use NetworkPolicy in the context of Kubernetes. The Kubernetes NetworkPolicy allows [pods][3] to receive traffic from anywhere. This is not ideal. To secure the pods, you must understand the endpoints pods can communicate within the Kubernetes construct.
1. Pod-to-pod communication using `podSelector`.
```
- namespaceSelector:
    matchLabels:
      project: myproject
```
2. Namespace-to-namespace communication and namespace-to-pod communication using `namespaceSelector` and/or a combination of `podSelector` and `namespaceSelector`.
```
- namespaceSelector:
    matchLabels:
      project: myproject
\- podSelector:
    matchLabels:
      role: frontend
```
3. IP blocks communication for pods using `ipBlock` to define which `IP CIDR` blocks dictate the source and destination.
```
- ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
```
Note the difference between pod, namespace, and IP-based policy. For pod and namespace-based NetworkPolicy, you use `selector` to control traffic, while for IP-based NetworkPolicy, controls get defined using `IP blocks` (CIDR ranges).
Putting it together, a NetworkPolicy should look like the following:
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 192.168.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
```
Referencing the NetworkPolicy above, notice the `spec` section. Under this section, `podSelector` with label _app=backend_ is the target of our NetworkPolicy. In short, the NetworkPolicy protects the application called _backend_ inside a given namespace.
This section also has `policyTypes` definition. This field indicates whether or not the given policy applies to ingress traffic to the selected pod, egress traffic from selected pods, or both.
```
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
```
Now, look at the `ingress` and `egress` section. This definition dictates the control of the NetworkPolicy.
First, examine the `ingress from` section.
The NetworkPolicy in this instance allows pod connection from:
* `ipBlock`
* Allow 172.17.0.0/16
* Deny192.168.1.0/24
* `namespaceSelector`
* `myproject`: Allow all pods from this namespace and with the same labels _project=myproject_.
* `podSelector`
* `frontend`: Allow pods that match the label _role=frontend_
```
ingress:
\- from:
  - ipBlock:
      cidr: 172.17.0.0/16
      except:
      - 192.168.1.0/24
  - namespaceSelector:
      matchLabels:
        project: myproject
  - podSelector:
      matchLabels:
        role: frontend
```
Now, examine the `egress to` section. This dictates the connection from the pod to:
* `ipBlock`
* 10.0.0.0/24: Connection to this CIDR is allowed
* Ports: Allowed to connect using TCP and port 5978
```
egress:
\- to:
  - ipBlock:
      cidr: 10.0.0.0/24
  ports:
  - protocol: TCP
    port: 5978
```
## NetworkPolicy limitations
NetworkPolicy alone cannot totally secure your Kubernetes clusters. You can use either the operating system components or Layer 7 technologies to overcome the known limitations. You need to remember that NetworkPolicy can only address security for IP address and port level—Open Systems Interconnection (OSI) layer 3 or 4.
To address security requirements that NetworkPolicy can't handle, you need to use other security solutions. Here are some [use cases][7] that you need to know where NetworkPolicy needs augmentation by other technologies.
## Summary
Understanding Kubernetes NetworkPolicy is important because it's a way to fulfill (but not replace) the firewall role that you usually use in a datacenter setup, but for Kubernetes. Think of this as the first layer of your container security, knowing that NetworkPolicy alone is not a total security solution.
NetworkPolicy applies security on pod and namespace using selectors and labels. In addition, NetworkPolicy can also enforce security through IP ranges.
Having a sound understanding of NetworkPolicy is an important skill towards secure adoption of containerization in the Kubernetes context.
--------------------------------------------------------------------------------
via: https://opensource.com/article/21/10/kubernetes-networkpolicy
作者：[Mike Calizo][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/mcalizo
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/containers_modules_networking_hardware_parts.png?itok=rPpVj92- (Parts, modules, containers for software)
[2]: https://kubernetes.io/docs/concepts/services-networking/network-policies/
[3]: https://kubernetes.io/docs/concepts/workloads/pods/
[4]: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/
[5]: https://github.com/containernetworking/cni
[6]: https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md
[7]: https://kubernetes.io/docs/concepts/services-networking/network-policies/#what-you-can-t-do-with-network-policies-at-least-not-yet

203
translated/tech/20211021 What you need to know about Kubernetes NetworkPolicy.md Normal file
View File

@ -0,0 +1,203 @@
[#]: subject: "What you need to know about Kubernetes NetworkPolicy"
[#]: via: "https://opensource.com/article/21/10/kubernetes-networkpolicy"
[#]: author: "Mike Calizo https://opensource.com/users/mcalizo"
[#]: collector: "lujun9972"
[#]: translator: "perfiffer"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
你需要了解的关于 Kubernetes <ruby>网络策略<rt>NetworkPolicy</rt></ruby> 的信息
======
在你通过 Kubernetes 部署一个应用之前，了解 Kubernetes <ruby>网络策略<rt>NetworkPolicy</rt></ruby> 是一个基本的要求。
![Parts, modules, containers for software][1]
随着越来越多的云原生应用程序通过 Kubernetes 部署到生产环境，安全性是你必须在早期就需要考虑的一个重要检查项。在设计云原生应用程序时，预先嵌入安全策略非常重要。不这样做会导致后续的安全问题，从而导致项目延迟，并最终给你带来不必要的压力和金钱投入。
多年来，人们在最后还是没有实现安全--直到他们的部署即将发布到生产环境。这种做法会导致项目交付的延迟，因为每个组织都有要遵守的安全标准，这些标准要么被绕过，要么没有遵循许多公认的风险来交付项目。
对于刚开始学习 Kubernetes 实现的来龙去脉的人来说，了解 Kubernetes <ruby>网络策略<rt>NetworkPolicy</rt></ruby> 可能会令人生畏。但这是在将应用程序部署到 Kubernetes 集群之前必须了解的基本要求之一。在学习 Kubernetes 和云原生应用程序时，请记住“不要把安全抛在脑后！”。
### NetworkPolicy 概念
[NetworkPolicy][2] 取代了数据中心环境中的防火墙设备--作为计算实例的 Pod、路由器和交换机的网络插件以及存储区域网络（SAN）的卷。
默认情况下，Kubernetes NetworkPolicy 允许 [Pod][3] 从任何地方接收流量。如果你不担心 Pod 的安全性，那么这可能没问题。但是，如果你正在运行关键工作负载，则需要保护 Pod。控制集群内的流量（包括入口和出口流量），可以通过 NetworkPolicy 实现。
要启用网络策略，你需要一个支持网络策略的网络插件。否则，你应用的任何规则都将变得毫无用处。
[Kubernetes.io][4] 上列出了不同的网络插件：
* CNI 插件：遵循[容器网络接口](5)（CNI）规范，旨在实现互操作性。
* Kubernetes 遵循 CNI 规范的 [v0.4.0][6] 版本。
* Kubernetes 插件：使用桥接器和主机本地 CNI 插件实现基本的 `cbr0`。
### 应用网络策略
要应用网络策略，你需要一个具有支持 NetworkPolicy 的网络插件的工作 Kubernetes 集群。
但首先，你需要了解如何在 Kubernetes 的上下文中使用 NetworkPolicy。Kubernetes NetworkPolicy 允许 [Pod][3] 从任何地方接收流量。这并不是理想情况。为了 Pod 安全性，你必须了解 Pod 是可以在 Kubernetes 架构内进行通信的端点。
1. 使用 `podSelector` 进行 Pod 到 Pod 的通信。
```
- namespaceSelector:
    matchLabels:
      project: myproject
```
2. 使用 `namespaceSelector` 和/或 `podSelector` 和 `namespaceSelector` 的组合进行命名空间到命名空间通信和命名空间到 Pod 通信。
```
- namespaceSelector:
    matchLabels:
      project: myproject
- podSelector:
    matchLabels:
      role: frontend
```
3. IP 阻止 Pod 之间的通信使用 `ipBlock` ，通过定义 `IP CIDR` 来指定源和目的地。
```
- ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
```
请注意 Pod、命名空间和基于 IP 的策略之间的区别。对于基于 Pod 和命名空间的 NetworkPolicy，使用选择器来控制流量，而对基于 IP 的 NetworkPolicy，使用 `IP blocks`（CIDR 范围）定义控制。
把它们放在一起，一个 NetworkPolicy 应如下所示：
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 192.168.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
```
参考上面的 NetworkPolicy，请注意 `spec` 部分。在此部分下，带有标签 app=backend 的 `podSelector` 是我们 NetworkPolicy 的目标。简而言之，NetworkPolicy 保护给定命名空间内称为后端的应用程序。
此部分也有 `policyTypes` 定义。此字段指示给定策略是否适用于选定 Pod 的入口流量、选定 Pod 的出口流量，或两者皆有。
```
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
```
现在，请看 `ingress` 和 `egress` 部分。该定义规定了 NetworkPolicy 的控制。
首先，检查 `ingress from` 部分。
此实例中，网络策略允许从以下位置进行 Pod 连接：
* `ipBlock`
* 允许 172.17.0.0/16
* 拒绝 192.168.1.0/24
* `namespaceSelector`
* `myproject`: 允许来自此命名空间并具有相同标签 project=myproject 的所有 Pod。
* `podSelector`
* `frontend`: 允许与标签 role=frontend 匹配的 Pod。
```
ingress:
- from:
  - ipBlock:
      cidr: 172.17.0.0/16
      except:
      - 192.168.1.0/24
  - namespaceSelector:
      matchLabels:
        project: myproject
  - podSelector:
      matchLabels:
        role: frontend
```
现在，检查 `egress to` 部分。这决定了从 pod 出去的连接：
* `ipBlock`
* 10.0.0.0/24: 允许连接到此 CIDR
* Ports: 允许使用 TCP 和端口 5978 进行连接
```
egress:
- to:
  - ipBlock:
      cidr: 10.0.0.0/24
  ports:
  - protocol: TCP
    port: 5978
```
## NetworkPolicy 限制
仅靠 NetworkPolicy 无法完全保护你的 Kubernetes 集群。你可以使用操作系统组件或 7 层网络技术来克服已知限制。你需要记住，NetworkPolicy 只能解决 IP 地址和端口级别的安全问题--即开放系统互联（OSI）中的第 3 层或第 4 层。
为了解决 NetworkPolicy 无法处理的安全要求，你需要使用其它安全解决方案。以下是一些你需要了解 NetworkPolicy 需要其它技术增强的[用例][7]。
## 总结
了解 Kubernetes NetworkPolicy 很重要，因为它是实现（但不是替代）你通常在数据中心设置中使用的防火墙角色的一种方式，但适用于 Kubernetes。将此视为容器安全的第一层，仅仅依靠 NetworkPolicy 并不是一个完整的安全解决方案。
NetworkPolicy 使用选择器和标签在 Pod 和命名空间上实现安全性。此外，NetworkPolicy 还可以通过 IP 范围强制实施安全性。
充分理解 NetworkPolicy 是在 Kubernetes 环境中安全采用容器化的一项重要技能。
--------------------------------------------------------------------------------
via: https://opensource.com/article/21/10/kubernetes-networkpolicy
作者：[Mike Calizo][a]
选题：[lujun9972][b]
译者：[perfiffer](https://github.com/perfiffer)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/mcalizo
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/containers_modules_networking_hardware_parts.png?itok=rPpVj92- (Parts, modules, containers for software)
[2]: https://kubernetes.io/docs/concepts/services-networking/network-policies/
[3]: https://kubernetes.io/docs/concepts/workloads/pods/
[4]: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/
[5]: https://github.com/containernetworking/cni
[6]: https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md
[7]: https://kubernetes.io/docs/concepts/services-networking/network-policies/#what-you-can-t-do-with-network-policies-at-least-not-yet