Use Network Policy in ACK Serverless clusters-Container Service for Kubernetes(ACK)-阿里云帮助中心

Enable Network Policy in ACK Serverless clusters to control pod-level traffic with the Poseidon component.

Prerequisites

An ACK managed cluster or ACK dedicated cluster is created. See Create an ACK managed cluster or Create an ACK dedicated cluster (Discontinued).
Important
In ACK managed cluster Pro and ACK Serverless Pro clusters, Network Policy is implemented by different components.
- In an ACK managed cluster Pro (for nodes that are not elastic container instances), Network Policy is implemented by the Terway network plugin. See Enable Network Policy in ACK clusters.
- In elastic container instances (ECIs) in ACK Serverless clusters and ACK managed Pro clusters, Network Policy is implemented by the Poseidon component.
The ACK Virtual Node component is upgraded to v2.10.0 or later. See Manage components.
A security group is configured for the cluster.
kubectl access to the cluster is configured.

Limitations

Network Policy is supported only in ACK Serverless Pro and ACK managed cluster Pro clusters.
Network Policy does not support IPv6 addresses.
The endPort field in a NetworkPolicy is not supported.
NetworkPolicy rules use label selectors to match namespaces or pods. Too many NetworkPolicy resources slow rule propagation and complicate management and troubleshooting. Limit NetworkPolicy resources to fewer than 40 per cluster.

Step 1: Enable Network Policy

Install the Poseidon component to enable Network Policy in an ACK Serverless Pro cluster.

Install the Poseidon component.
1. Log on to the ACK console. In the left navigation pane, click Clusters.
2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Components and Add-ons.
3. On the Add-ons page, click the Networking tab. On the Poseidon card, click Install.
4. In the Install Poseidon dialog box, select Enable NetworkPolicy for ACS/ECI instances and click OK.
  
  After installation, Installed appears on the card.

Step 2: Create and test an nginx application

Use the console

Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of the target cluster and in the left navigation pane, choose Workloads > Deployments.

On the Deployments page, click Create from Image. In the Create wizard, create an application named nginx and expose it using a Service. After configuring the application, click Create.

For this example, configure only the following items for the Nginx application and keep the default settings for the other parameters. For more information about the configurations, see Create a stateless workload (Deployment).

Configuration item		Description	Example value
Basic Information	Name	A custom name.	nginx
Basic Information	Replicas	Select as needed.	1
Container	Image Name	The name of the image used to start the container.	nginx:latest
Advanced	Services	To the right of Services, click Create to set the service configuration items.	Name: nginx
			Service Type: Cluster IP SLB Node Port
			Port Mapping: Name: nginx Service Port: 80 Container Port: 80 Protocol: TCP

On the Deployments page, click Create from Image. In the resulting Create wizard, create a client application named busybox to test access to the nginx Service that you created in the previous step.

For this example, configure only the following items for the busybox client application and keep the default settings for the other parameters. For more information about the configurations, see Create a stateless workload (Deployment).

Configuration item		Description	Example value
Basic Information	Name	A custom name.	busybox
Basic Information	Replicas	Set a value as needed.	1
Container	Image Name	The name of the image used to start the container.	busybox:latest
Container	Container Start Parameter	None	Select stdin and tty

Verify that the busybox client application can access the Nginx Service.
1. On the Deployments page, click the busybox application name.
2. On the Pods tab, locate the busybox-{hash value} pod and click Terminal in the Actions column.
3. In the busybox command-line terminal, run the wget nginx command to test access to Nginx.
  The output indicates that busybox can access the Nginx Service.

Use the CLI

Run the following commands to create an Nginx application and expose it using a Service named nginx.

Create an Nginx application:

kubectl run nginx --image=nginx

Expected output:

pod/nginx created

Check whether the pod is started:

kubectl get pod

Expected output:

NAME                     READY   STATUS    RESTARTS   AGE
nginx                    1/1     Running   0          45s

Create a Service named nginx:

kubectl expose pod nginx --port=80

Expected output:

service/nginx exposed

View the Service:

kubectl get service

Expected output:

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.XX.XX.1     <none>        443/TCP   30m
nginx        ClusterIP   172.XX.XX.48    <none>        80/TCP    12s

Run the following command to create a pod named busybox and access the Service named nginx.

kubectl run busybox --rm -ti --image=busybox /bin/sh

Expected output:

If you don't see a command prompt, try pressing enter.
/ #
/ #

Access nginx:

If you don't see a command prompt, try pressing enter.
/ #
/ # wget nginx  # Enter wget nginx here.

Expected output:

Connecting to nginx (172.XX.XX.48:80)
saving to 'index.html'
index.html           100% |****************************************************************************************************************************************************|   612  0:00:00 ETA
'index.html' saved

Step 3: Use a network policy

Apply NetworkPolicy resources to restrict pod traffic by label, CIDR block, egress destination, or public network access.

Scenario 1: Restrict service access to applications with specific labels using a network policy

Run the vim policy.yaml command to create a file named policy.yaml, and populate it with the following YAML template.

vim policy.yaml

The following is the content of the YAML file.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

Run the following command to create a network policy from the policy.yaml file.
```
kubectl apply -f policy.yaml 
```
Expected output:
```
networkpolicy.networking.k8s.io/access-nginx created
```

Run the following commands to test access to the nginx Service. Because no access label is defined, the request times out.

kubectl run busybox --rm -ti --image=busybox /bin/sh

Test access to the nginx Service:

wget nginx

Expected output:

Connecting to nginx (172.19.XX.XX:80)
wget: can't connect to remote host (172.19.XX.XX): Connection timed out

Run the following commands to define the access label.

kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh

Test access to the Nginx Service:

wget nginx

Expected output:

Connecting to nginx (172.21.XX.XX:80)
saving to 'index.html'
index.html           100% |****************************************************************************************************************************************************|   612  0:00:00 ETA
'index.html' saved

The output indicates that the connection progress is 100%. This means that the request is successful and the Nginx service can be accessed.

Scenario 2: Restrict the source CIDR blocks that can access an Internet-facing service using a network policy

Run the following command to create an Alibaba Cloud SLB instance for the nginx application. Specify type=LoadBalancer to expose the nginx service to the Internet.

vim nginx-service.yaml

The following is the template for the nginx-service.yaml file.

# Paste the following YAML content into nginx-service.yaml.
apiVersion: v1
kind: Service
metadata:
  labels:
    run: nginx
  name: nginx-slb
spec:
  externalTrafficPolicy: Local
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

Run the following command to create a network policy from the nginx-service.yaml file.

kubectl apply -f nginx-service.yaml

Expected output:

service/nginx-slb created

Check whether the application exposes the Nginx service:

kubectl get service nginx-slb

Expected output:

NAME        TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
nginx-slb   LoadBalancer   172.19.xx.xxx   47.110.xxx.xxx   80:32240/TCP   8m

Run the following command to access the IP address of the newly created SLB instance, 47.110.xxx.xxx. Access fails.
```
wget 47.110.xxx.xxx
```
Expected output:
```
--2018-11-21 11:46:05--  http://47.110.xx.xxx/
Connecting to 47.110.XX.XX:80... failed: Connection refused.
```
Note
Access fails for the following reasons:
The configured nginx Service can only be accessed by applications with the specific label access=true.
Accessing the IP address of the SLB instance is considered external access to Kubernetes. This is different from the scenario of restricting service access to applications with specific labels.
Solution: Modify the network policy to add the allowed source CIDR block.

Run the following command to view your local IP address.

curl myip.ipip.net

Expected output:

Current IP: 10.0.x.x From: China Beijing Beijing        # This is an example. Use the actual device information.

Run the following command to modify the policy.yaml file.

vim policy.yaml

Modify the policy.yaml file to include the following content:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
    - ipBlock:
        cidr: 100.64.0.0/10
    - ipBlock:
        cidr: 10.0.0.1/24      # Local IP address. This is an example. Use the actual device information.

Run the following command to create a network policy from the policy.yaml file.

kubectl apply -f policy.yaml

Expected output:

networkpolicy.networking.k8s.io/access-nginx unchanged

Note

Some networks have multiple egress IP addresses. We recommend that you use a /24 address range.
The SLB health check addresses are in the 100.64.0.0/10 CIDR block. Therefore, you must add 100.64.0.0/10 to the allowed list.

Run the following command to access the Nginx service.

kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh

Access the nginx service:

wget 47.110.XX.XX

Expected output:

Connecting to 47.110.XX.XX (47.110.XX.XX:80)
index.html           100% |***********************************************************|   612  0:00:00 ETA

The output indicates that the connection progress is 100%. This means that you have successfully accessed the Nginx service.

Scenario 3: Restrict a pod to access only a specified address using a network policy

Run the following command to obtain the list of IP addresses to which the www.aliyun.com domain name resolves.

dig +short www.aliyun.com

Expected output:

www-jp-de-intl-adns.aliyun.com.
www-jp-de-intl-adns.aliyun.com.gds.alibabadns.com.
v6wagbridge.aliyun.com.
v6wagbridge.aliyun.com.gds.alibabadns.com.
106.XX.XX.21
140.XX.XX.4
140.XX.XX.13
140.XX.XX.3

Create a file named busybox-policy.yaml.

vim busybox-policy.yaml

Use the following template for the busybox-policy.yaml file:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: busybox-policy
spec:
  podSelector:
    matchLabels:
      run: busybox
  egress:
  - to:
    - ipBlock:
        cidr: 106.XX.XX.21/32
    - ipBlock:
        cidr: 140.XX.XX.4/32
    - ipBlock:
        cidr: 140.XX.XX.13/32
    - ipBlock:
        cidr: 140.XX.XX.3/32
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53

Note

In the busybox-policy.yaml file, egress rules are configured to restrict the application's outbound access. You must configure the rules to allow UDP requests. Otherwise, DNS resolution fails.

Run the following command to create a network policy from the busybox-policy.yaml file.
```
kubectl apply -f busybox-policy.yaml 
```
Expected output:
```
networkpolicy.networking.k8s.io/busybox-policy created
```
Run the following command to create a busybox pod and test access.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Access a website other than www.aliyun.com, such as www.taobao.com:
```
wget www.taobao.com
```
Expected output:
```
Connecting to www.taobao.com (64.13.XX.XX:80)
wget: can't connect to remote host (64.13.XX.XX): Connection timed out
```
The can't connect to remote host message indicates that access failed.

Run the following command to access www.aliyun.com.

wget www.aliyun.com

Expected output:

Connecting to www.aliyun.com (140.205.XX.XX:80)
Connecting to www.aliyun.com (140.205.XX.XX:443)
wget: note: TLS certificate validation not implemented
index.html           100% |***********************************************************|  462k  0:00:00 ETA

The output indicates that the connection progress is 100%. This means that the service was accessed successfully.

Scenario 4: Control public network access for pods in a namespace using a network policy

Important

This operation may affect online services that are accessing the public network. We recommend that you perform the following operations in an empty namespace.

Run the following command to create a test namespace.
Create a namespace named test-np.
```
kubectl create ns test-np
```
Expected output:
```
namespace/test-np created
```

Run the following command to create a default network policy for the namespace that allows only outbound access to private networks.

vim default-deny.yaml

The following is an example template for the default-deny.yaml file:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: test-np
  name: deny-public-net
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.0.0/16
    - ipBlock:
        cidr: 172.16.0.0/12
    - ipBlock:
        cidr: 10.0.0.0/8

Verify that the default-deny.yaml file has been created.

kubectl apply -f default-deny.yaml

Expected output:

networkpolicy.networking.k8s.io/deny-public-net created

View the network policy:

kubectl get networkpolicy -n test-np

Expected output:

NAME                              POD-SELECTOR          AGE
deny-public-net                   <none>                1m

Run the following command to create a network policy that allows pods with a specific label to access the public network.

vim allow-specify-label.yaml

In this example, the label is public-network=true.

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-public-network-for-labels
  namespace: test-np
spec:
  podSelector:
    matchLabels:
      public-network: "true"
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    - namespaceSelector:
        matchLabels:
          ns: kube-system  # Allows pods to access key services in kube-system (such as CoreDNS). This is an example. Configure as needed.

Run the following command to create the network policy:

kubectl apply -f allow-specify-label.yaml

Expected output:

networkpolicy.networking.k8s.io/allow-public-network-for-labels created

View the network policy:

kubectl get networkpolicy -n test-np

Expected output:

NAME                              POD-SELECTOR          AGE
allow-public-network-for-labels   public-network=true    1m
deny-public-net                   <none>                 3m

Run the following commands to verify that a pod without the special label cannot access the public network.
```
kubectl run -it --namespace test-np --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-intranet
```
```
ping aliyun.com
```
Expected output:
```
PING aliyun.com (106.11.2xx.xxx): 56 data bytes
^C
--- aliyun.com ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
```
The 0 packets received message indicates that access failed.
Note
Access failed because the deny-public-net network policy restricts public network access for pods in the test-np namespace by default. Therefore, pods that are started in this namespace with default labels cannot access the public network.

Run the following command to verify that a pod with the public-network=true label can access the public network.

kubectl run -it --namespace test-np --labels public-network=true --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-internet

ping aliyun.com

Expected output:

PING aliyun.com (106.11.1xx.xx): 56 data bytes
64 bytes from 106.11.1xx.xx: seq=0 ttl=47 time=4.235 ms
64 bytes from 106.11.1xx.xx: seq=1 ttl=47 time=4.200 ms
64 bytes from 106.11.1xx.xx: seq=2 ttl=47 time=4.182 ms
^C
--- aliyun.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 4.182/4.205/4.235 ms

The 0% packet loss message indicates that the service was accessed successfully.

Note

Access is successful because the allow-public-network-for-labels network policy allows public network access for pods with the public-network=true label. Therefore, the busybox-internet pod, which has this label, can access the public network.