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

选题[tech]: 20211021 What you need to know about Kubernetes NetworkPolicy

Browse Source 
sources/tech/20211021 What you need to know about Kubernetes NetworkPolicy.md
This commit is contained in:
DarkSun 2021-11-04 17:42:02 +08:00
parent aaff325d10
commit 8f1f95c08d
1 changed files with 137 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -19,7 +19,7 @@ For years, people left security at the end—until their deployment was about to
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
### 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).
@ -35,34 +35,43 @@ There a different network plugins [listed on Kubernetes.io][4]:
## Applying a network policy
### 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`. [code] - namespaceSelector:
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`. [code] - namespaceSelector:
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
      role: frontend
```
3. IP blocks communication for pods using `ipBlock` to define which `IP CIDR` blocks dictate the source and destination. [code] - ipBlock:
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:
@ -83,4 +92,123 @@ spec:
        - 192.168.1.0/24
    - namespaceSelector:
        matchLabels:
          projec
          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