Use Network Policy in ACK Serverless clusters - Container Service for Kubernetes

Habilite Network Policy en los clústeres ACK Serverless para controlar el tráfico a nivel de pod con el complemento Poseidon.

Requisitos previos

Se creó un clúster administrado de ACK o un clúster dedicado de ACK. Consulte Create an ACK managed cluster o Create an ACK dedicated cluster (Discontinued).
Importante
En los clústeres ACK managed cluster Pro y ACK Serverless Pro, distintos complementos implementan Network Policy.
- En un ACK managed cluster Pro (para nodos que no son elastic container instances), el plugin de red Terway implementa Network Policy. Consulte Enable Network Policy in ACK clusters.
- En las elastic container instances (ECI) de los clústeres ACK Serverless y los clústeres ACK managed Pro, el complemento Poseidon implementa Network Policy.
El complemento ACK Virtual Node se actualizó a la versión v2.10.0 o posterior. Consulte Manage components.
Un security group is configured for the cluster.
kubectl access to the cluster is configured.

Limitaciones

Network Policy solo es compatible con los clústeres ACK Serverless Pro y ACK managed cluster Pro.
Network Policy no admite direcciones IPv6.
El campo endPort de una NetworkPolicy no es compatible.
Las reglas de NetworkPolicy usan selectores de etiquetas para coincidir con namespaces o pods. Un exceso de recursos NetworkPolicy ralentiza la propagación de reglas y complica la gestión y solución de problemas. Limite los recursos NetworkPolicy a menos de 40 por clúster.

Paso 1: Habilitar Network Policy

Instale el complemento Poseidon para habilitar Network Policy en un clúster ACK Serverless Pro.

Instale el complemento Poseidon.
1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.
2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Components and Add-ons .
3. En la página Components and Add-ons, haga clic en Install. En la pestaña Networking, busque la tarjeta Poseidon y haga clic en Next.
4. En el cuadro de diálogo Install Component, seleccione Enable NetworkPolicy for ACS/ECI Instances, haga clic en Next y luego en OK.
  
  Una vez finalizada la instalación, aparece Installed en la tarjeta.

Paso 2: Crear y probar una aplicación nginx

Usar la consola

Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.
En la página Clusters, haga clic en el nombre del clúster de destino. En el panel de navegación izquierdo, elija Workloads > Deployments.

En la página Deployments, haga clic en Create from Image. En el asistente Create, cree una aplicación llamada nginx y expóngala mediante un Service. Después de configurar la aplicación, haga clic en Create.

Para este ejemplo, configure únicamente los siguientes elementos de la aplicación Nginx y conserve la configuración predeterminada en los demás parámetros. Para obtener más información sobre las configuraciones, consulte Create a stateless workload (Deployment).

Elemento de configuración		Descripción	Valor de ejemplo
Basic Information	Name	Un nombre personalizado.	nginx
Basic Information	Replicas	Seleccione según sus necesidades.	1
Container	Image Name	El nombre de la imagen utilizada para iniciar el contenedor.	nginx:latest
Advanced	Services	A la derecha de Services, haga clic en Create para establecer los elementos de configuración del servicio.	Name: nginx
			Service Type: Cluster IP SLB Node Port
			Port Mapping: Name: nginx Service Port: 80 Container Port: 80 Protocol: TCP

En la página Deployments, haga clic en Create from Image. En el asistente Create resultante, cree una aplicación cliente llamada busybox para probar el acceso al Service nginx que creó en el paso anterior.

Para este ejemplo, configure únicamente los siguientes elementos de la aplicación cliente busybox y conserve la configuración predeterminada en los demás parámetros. Para obtener más información sobre las configuraciones, consulte Create a stateless workload (Deployment).

Elemento de configuración		Descripción	Valor de ejemplo
Basic Information	Name	Un nombre personalizado.	busybox
Basic Information	Replicas	Establezca un valor según sus necesidades.	1
Container	Image Name	El nombre de la imagen utilizada para iniciar el contenedor.	busybox:latest
Container	Container Start Parameter	Ninguna	Seleccione stdin y tty

Compruebe que la aplicación cliente busybox pueda acceder al Service Nginx.
1. En la página Deployments, haga clic en el nombre de la aplicación busybox.
2. En la pestaña Pods, ubique el pod busybox-{valor de hash} y haga clic en Terminal dentro de la columna Actions.
3. En la terminal de línea de comandos de busybox, ejecute el comando wget nginx para probar el acceso a Nginx.
  
  La salida indica que busybox puede acceder al Service Nginx.

Usar la CLI

Ejecute los siguientes comandos para crear una aplicación Nginx y exponerla mediante un Service llamado nginx.

Cree una aplicación Nginx:

kubectl run nginx --image=nginx

Salida esperada:

pod/nginx created

Compruebe si el pod se inició:

kubectl get pod

Salida esperada:

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

Cree un Service llamado nginx:

kubectl expose pod nginx --port=80

Salida esperada:

service/nginx exposed

Consulte el Service:

kubectl get service

Salida esperada:

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

Ejecute el siguiente comando para crear un pod llamado busybox y acceder al Service nginx.

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

Salida esperada:

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

Acceda a nginx:

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

Salida esperada:

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

Paso 3: Usar una network policy

Aplique recursos NetworkPolicy para restringir el tráfico de los pods por etiqueta, bloque CIDR, destino de egreso o acceso a la red pública.

Escenario 1: Restringir el acceso al servicio a aplicaciones con etiquetas específicas mediante una network policy

Ejecute el comando vim policy.yaml para crear un archivo llamado policy.yaml y llénelo con la siguiente plantilla YAML.

vim policy.yaml

A continuación se muestra el contenido del archivo YAML.

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

Ejecute el siguiente comando para crear una network policy a partir del archivo policy.yaml.
```
kubectl apply -f policy.yaml 
```
Salida esperada:
```
networkpolicy.networking.k8s.io/access-nginx created
```
Ejecute los siguientes comandos para probar el acceso al Service nginx. Como no se definió ninguna etiqueta de acceso, la solicitud agota el tiempo de espera.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Pruebe el acceso al Service nginx:
```
wget nginx
```
Salida esperada:
```
Connecting to nginx (172.19.XX.XX:80)
wget: can't connect to remote host (172.19.XX.XX): Connection timed out
```

Ejecute los siguientes comandos para definir la etiqueta de acceso.

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

Pruebe el acceso al Service Nginx:

wget nginx

Salida esperada:

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

La salida indica que el progreso de la conexión es del 100 %. Esto significa que la solicitud se completó correctamente y se puede acceder al servicio Nginx.

Escenario 2: Restringir los bloques CIDR de origen que pueden acceder a un servicio expuesto a Internet mediante una network policy

Ejecute el siguiente comando para crear una instancia SLB de Alibaba Cloud para la aplicación nginx. Especifique type=LoadBalancer para exponer el servicio nginx a Internet.

vim nginx-service.yaml

A continuación se muestra la plantilla del archivo nginx-service.yaml.

# 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

Ejecute el siguiente comando para crear una network policy a partir del archivo nginx-service.yaml.

kubectl apply -f nginx-service.yaml

Salida esperada:

service/nginx-slb created

Compruebe si la aplicación expone el servicio Nginx:

kubectl get service nginx-slb

Salida esperada:

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

Ejecute el siguiente comando para acceder a la dirección IP de la instancia SLB recién creada, 47.110.xxx.xxx. El acceso falla.
```
wget 47.110.xxx.xxx
```
Salida esperada:
```
--2018-11-21 11:46:05--  http://47.110.xx.xxx/
Connecting to 47.110.XX.XX:80... failed: Connection refused.
```
Nota
El acceso falla por las siguientes razones:

Solo las aplicaciones con la etiqueta específica access=true pueden acceder al Service nginx configurado.

Acceder a la dirección IP de la instancia SLB se considera un acceso externo a Kubernetes. Este caso difiere del escenario donde se restringe el acceso al servicio a aplicaciones con etiquetas específicas.
Solución: modifique la network policy para agregar el bloque CIDR de origen permitido.

Ejecute el siguiente comando para consultar su dirección IP local.

curl myip.ipip.net

Salida esperada:

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

Ejecute el siguiente comando para modificar el archivo policy.yaml.

vim policy.yaml

Modifique el archivo policy.yaml para incluir el siguiente contenido:

# 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.

Ejecute el siguiente comando para crear una network policy a partir del archivo policy.yaml.

kubectl apply -f policy.yaml

Salida esperada:

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

Nota

Algunas redes tienen varias direcciones IP de egreso. Se recomienda usar un rango de direcciones /24.
Las direcciones de comprobación de estado de SLB pertenecen al bloque CIDR 100.64.0.0/10. Por lo tanto, debe agregar 100.64.0.0/10 a la lista de permitidos.

Ejecute el siguiente comando para acceder al servicio Nginx.

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

Acceda al servicio nginx:

wget 47.110.XX.XX

Salida esperada:

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

La salida indica que el progreso de la conexión es del 100 %. Esto significa que accedió correctamente al servicio Nginx.

Escenario 3: Restringir un pod para que acceda únicamente a una dirección específica mediante una network policy

Ejecute el siguiente comando para obtener la lista de direcciones IP a las que resuelve el nombre de dominio www.aliyun.com.

dig +short www.aliyun.com

Salida esperada:

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

Cree un archivo llamado busybox-policy.yaml.

vim busybox-policy.yaml

Utilice la siguiente plantilla para el archivo busybox-policy.yaml:

# 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

Nota

En el archivo busybox-policy.yaml, las reglas de egreso se configuran para restringir el acceso saliente de la aplicación. Debe configurar las reglas para permitir solicitudes UDP; de lo contrario, la resolución DNS fallará.

Ejecute el siguiente comando para crear una network policy a partir del archivo busybox-policy.yaml.
```
kubectl apply -f busybox-policy.yaml 
```
Salida esperada:
```
networkpolicy.networking.k8s.io/busybox-policy created
```
Ejecute el siguiente comando para crear un pod busybox y probar el acceso.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Acceda a un sitio web distinto de www.aliyun.com, como www.taobao.com:
```
wget www.taobao.com
```
Salida esperada:
```
Connecting to www.taobao.com (64.13.XX.XX:80)
wget: can't connect to remote host (64.13.XX.XX): Connection timed out
```
El mensaje can't connect to remote host indica que el acceso falló.

Ejecute el siguiente comando para acceder a www.aliyun.com.

wget www.aliyun.com

Salida esperada:

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

La salida indica que el progreso de la conexión es del 100 %. Esto significa que se accedió correctamente al servicio.

Escenario 4: Controlar el acceso a la red pública de los pods en un namespace mediante una network policy

Importante

Esta operación puede afectar los servicios en producción que acceden a la red pública. Se recomienda ejecutar las siguientes operaciones en un namespace vacío.

Ejecute el siguiente comando para crear un namespace de prueba.
Cree un namespace llamado test-np.
```
kubectl create ns test-np
```
Salida esperada:
```
namespace/test-np created
```

Ejecute el siguiente comando para crear una network policy predeterminada en el namespace que permita únicamente el acceso saliente a redes privadas.

vim default-deny.yaml

A continuación se muestra una plantilla de ejemplo para el archivo default-deny.yaml:

# 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

Compruebe que se haya creado el archivo default-deny.yaml.

kubectl apply -f default-deny.yaml

Salida esperada:

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

Consulte la network policy:

kubectl get networkpolicy -n test-np

Salida esperada:

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

Ejecute el siguiente comando para crear una network policy que permita a los pods con una etiqueta específica acceder a la red pública.

vim allow-specify-label.yaml

En este ejemplo, la etiqueta es 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.

Ejecute el siguiente comando para crear la network policy:

kubectl apply -f allow-specify-label.yaml

Salida esperada:

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

Consulte la network policy:

kubectl get networkpolicy -n test-np

Salida esperada:

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

Ejecute los siguientes comandos para comprobar que un pod sin la etiqueta especial no puede acceder a la red pública.
```
kubectl run -it --namespace test-np --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-intranet
```
```
ping aliyun.com
```
Salida esperada:
```
PING aliyun.com (106.11.2xx.xxx): 56 data bytes
^C
--- aliyun.com ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
```
El mensaje 0 packets received indica que el acceso falló.

Nota
El acceso falló porque la network policy deny-public-net restringe de forma predeterminada el acceso a la red pública para los pods del namespace test-np. Por lo tanto, los pods iniciados en este namespace con etiquetas predeterminadas no pueden acceder a la red pública.

Ejecute el siguiente comando para comprobar que un pod con la etiqueta public-network=true puede acceder a la red pública.

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

Salida esperada:

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

El mensaje 0% packet loss indica que se accedió correctamente al servicio.

Nota

El acceso se completó correctamente porque la network policy allow-public-network-for-labels permite el acceso a la red pública para los pods con la etiqueta public-network=true. Por lo tanto, el pod busybox-internet, que tiene esta etiqueta, puede acceder a la red pública.