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

Activez Network Policy dans les clusters ACK Serverless pour contrôler le trafic au niveau des pods avec le module complémentaire Poseidon.

Prérequis

Un cluster ACK managé ou un cluster ACK dédié est créé. Consultez la rubrique Créer un cluster ACK managé ou Créer un cluster ACK dédié (obsolète).
Important
Dans les clusters ACK managed cluster Pro et ACK Serverless Pro, Network Policy est implémenté par différents modules complémentaires.
- Dans un cluster ACK managed cluster Pro (pour les nœuds qui ne sont pas des instances de conteneur élastiques), Network Policy est implémenté par le plug-in réseau Terway. Consultez la rubrique Activer Network Policy dans les clusters ACK.
- Dans les instances de conteneur élastiques (ECI) des clusters ACK Serverless et des clusters ACK managed Pro, Network Policy est implémenté par le module complémentaire Poseidon.
Le module complémentaire ACK Virtual Node est mis à niveau vers la version 2.10.0 ou ultérieure. Consultez la rubrique Gérer les composants.
Un groupe de sécurité est configuré pour le cluster.
L'accès kubectl au cluster est configuré.

Limites

Network Policy est pris en charge uniquement dans les clusters ACK Serverless Pro et ACK managed cluster Pro.
Network Policy ne prend pas en charge les adresses IPv6.
Le champ endPort d'une NetworkPolicy n'est pas pris en charge.
Les règles NetworkPolicy utilisent des sélecteurs d'étiquettes pour faire correspondre les namespaces ou les pods. Un nombre excessif de ressources NetworkPolicy ralentit la propagation des règles et complique la gestion et le dépannage. Limitez le nombre de ressources NetworkPolicy à moins de 40 par cluster.

Étape 1 : Activer Network Policy

Installez le module complémentaire Poseidon pour activer Network Policy dans un cluster ACK Serverless Pro.

Installez le module complémentaire Poseidon.
1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Components and Add-ons .
3. Sur la page Components and Add-ons, cliquez sur Install. Dans l'onglet Networking, localisez la carte Poseidon, puis cliquez sur Next.
4. Dans la boîte de dialogue Install Component, sélectionnez Enable NetworkPolicy for ACS/ECI Instances, cliquez sur Next, puis sur OK.
  
  Après l'installation, l'état Installed s'affiche sur la carte.

Étape 2 : Créer et tester une application nginx

Utiliser la console

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster cible et, dans le volet de navigation de gauche, choisissez Workloads > Deployments.

Sur la page Deployments, cliquez sur Create from Image. Dans l'assistant Create, créez une application nommée nginx et exposez-la à l'aide d'un Service. Après avoir configuré l'application, cliquez sur Create.

Pour cet exemple, configurez uniquement les éléments suivants pour l'application Nginx et conservez les paramètres par défaut pour les autres. Pour plus d'informations sur les configurations, consultez la rubrique Créer une charge de travail sans état (Deployment).

Élément de configuration		Description	Valeur d'exemple
Basic Information	Name	Un nom personnalisé.	nginx
Basic Information	Replicas	Sélectionnez selon vos besoins.	1
Container	Image Name	Le nom de l'image utilisée pour démarrer le conteneur.	nginx:latest
Advanced	Services	À droite de Services, cliquez sur Create pour définir les éléments de configuration du service.	Name : nginx
			Service Type : Cluster IP SLB Node Port
			Port Mapping : Name : nginx Service Port : 80 Container Port : 80 Protocol : TCP

Sur la page Deployments, cliquez sur Create from Image. Dans l'assistant Create qui s'affiche, créez une application cliente nommée busybox pour tester l'accès au Service nginx que vous avez créé à l'étape précédente.

Pour cet exemple, configurez uniquement les éléments suivants pour l'application cliente busybox et conservez les paramètres par défaut pour les autres. Pour plus d'informations sur les configurations, consultez la rubrique Créer une charge de travail sans état (Deployment).

Élément de configuration		Description	Valeur d'exemple
Basic Information	Name	Un nom personnalisé.	busybox
Basic Information	Replicas	Définissez une valeur selon vos besoins.	1
Container	Image Name	Le nom de l'image utilisée pour démarrer le conteneur.	busybox:latest
Container	Container Start Parameter	Aucun	Sélectionnez stdin et tty

Vérifiez que l'application cliente busybox peut accéder au Service Nginx.
1. Sur la page Deployments, cliquez sur le nom de l'application busybox.
2. Dans l'onglet Pods, localisez le pod busybox-{hash value} et cliquez sur Terminal dans la colonne Actions.
3. Dans le terminal de ligne de commande busybox, exécutez la commande wget nginx pour tester l'accès à Nginx.
  
  La sortie indique que busybox peut accéder au Service Nginx.

Utiliser la CLI

Exécutez les commandes suivantes pour créer une application Nginx et l'exposer à l'aide d'un Service nommé nginx.

Créez une application Nginx :

kubectl run nginx --image=nginx

Sortie attendue :

pod/nginx created

Vérifiez si le pod a démarré :

kubectl get pod

Sortie attendue :

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

Créez un Service nommé nginx :

kubectl expose pod nginx --port=80

Sortie attendue :

service/nginx exposed

Affichez le Service :

kubectl get service

Sortie attendue :

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

Exécutez la commande suivante pour créer un pod nommé busybox et accéder au Service nommé nginx.

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

Sortie attendue :

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

Accédez à nginx :

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

Sortie attendue :

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

Étape 3 : Utiliser une network policy

Appliquez des ressources NetworkPolicy pour restreindre le trafic des pods par étiquette, bloc CIDR, destination de sortie ou accès au réseau public.

Scénario 1 : Restreindre l'accès aux services aux applications portant des étiquettes spécifiques à l'aide d'une network policy

Exécutez la commande vim policy.yaml pour créer un fichier nommé policy.yaml et remplissez-le avec le modèle YAML suivant.

vim policy.yaml

Voici le contenu du fichier YAML.

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

Exécutez la commande suivante pour créer une network policy à partir du fichier policy.yaml.
```
kubectl apply -f policy.yaml 
```
Sortie attendue :
```
networkpolicy.networking.k8s.io/access-nginx created
```
Exécutez les commandes suivantes pour tester l'accès au Service nginx. Comme aucune étiquette d'accès n'est définie, la requête expire.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Testez l'accès au Service nginx :
```
wget nginx
```
Sortie attendue :
```
Connecting to nginx (172.19.XX.XX:80)
wget: can't connect to remote host (172.19.XX.XX): Connection timed out
```

Exécutez les commandes suivantes pour définir l'étiquette d'accès.

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

Testez l'accès au Service Nginx :

wget nginx

Sortie attendue :

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

La sortie indique que la progression de la connexion est de 100 %. Cela signifie que la requête a abouti et que le service Nginx est accessible.

Scénario 2 : Restreindre les blocs CIDR source pouvant accéder à un service exposé sur Internet à l'aide d'une network policy

Exécutez la commande suivante pour créer une instance Alibaba Cloud SLB pour l'application nginx. Spécifiez type=LoadBalancer pour exposer le service nginx à Internet.

vim nginx-service.yaml

Voici le modèle pour le fichier 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

Exécutez la commande suivante pour créer une network policy à partir du fichier nginx-service.yaml.

kubectl apply -f nginx-service.yaml

Sortie attendue :

service/nginx-slb created

Vérifiez si l'application expose le service Nginx :

kubectl get service nginx-slb

Sortie attendue :

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

Exécutez la commande suivante pour accéder à l'adresse IP de l'instance SLB nouvellement créée, 47 110.xxx.xxx. L'accès échoue.
```
wget 47.110.xxx.xxx
```
Sortie attendue :
```
--2018-11-21 11:46:05--  http://47.110.xx.xxx/
Connecting to 47.110.XX.XX:80... failed: Connection refused.
```
Remarque
L'accès échoue pour les raisons suivantes :

Le Service nginx configuré ne peut être accédé que par les applications portant l'étiquette spécifique access=true.

L'accès à l'adresse IP de l'instance SLB est considéré comme un accès externe à Kubernetes. Cela diffère du scénario de restriction de l'accès aux services aux applications portant des étiquettes spécifiques.
Solution : Modifiez la network policy pour ajouter le bloc CIDR source autorisé.

Exécutez la commande suivante pour afficher votre adresse IP locale.

curl myip.ipip.net

Sortie attendue :

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

Exécutez la commande suivante pour modifier le fichier policy.yaml.

vim policy.yaml

Modifiez le fichier policy.yaml pour inclure le contenu suivant :

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

Exécutez la commande suivante pour créer une network policy à partir du fichier policy.yaml.

kubectl apply -f policy.yaml

Sortie attendue :

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

Remarque

Certains réseaux possèdent plusieurs adresses IP de sortie. Nous vous recommandons d'utiliser une plage d'adresses /24.
Les adresses de contrôle d'intégrité SLB se trouvent dans le bloc CIDR 100.64.0.0/10. Par conséquent, vous devez ajouter 100.64.0.0/10 à la liste des autorisations.

Exécutez la commande suivante pour accéder au service Nginx.

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

Accédez au service nginx :

wget 47.110.XX.XX

Sortie attendue :

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

La sortie indique que la progression de la connexion est de 100 %. Cela signifie que vous avez accédé avec succès au service Nginx.

Scénario 3 : Restreindre un pod à l'accès uniquement à une adresse spécifiée à l'aide d'une network policy

Exécutez la commande suivante pour obtenir la liste des adresses IP vers lesquelles le nom de domaine www.aliyun.com se résout.

dig +short www.aliyun.com

Sortie attendue :

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

Créez un fichier nommé busybox-policy.yaml.

vim busybox-policy.yaml

Utilisez le modèle suivant pour le fichier 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

Remarque

Dans le fichier busybox-policy.yaml, des règles de sortie (egress) sont configurées pour restreindre l'accès sortant de l'application. Vous devez configurer les règles pour autoriser les requêtes UDP. Sinon, la résolution DNS échouera.

Exécutez la commande suivante pour créer une network policy à partir du fichier busybox-policy.yaml.
```
kubectl apply -f busybox-policy.yaml 
```
Sortie attendue :
```
networkpolicy.networking.k8s.io/busybox-policy created
```
Exécutez la commande suivante pour créer un pod busybox et tester l'accès.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Accédez à un site Web autre que www.aliyun.com, tel que www.taobao.com :
```
wget www.taobao.com
```
Sortie attendue :
```
Connecting to www.taobao.com (64.13.XX.XX:80)
wget: can't connect to remote host (64.13.XX.XX): Connection timed out
```
Le message can't connect to remote host indique que l'accès a échoué.

Exécutez la commande suivante pour accéder à www.aliyun.com.

wget www.aliyun.com

Sortie attendue :

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 sortie indique que la progression de la connexion est de 100 %. Cela signifie que le service a été accédé avec succès.

Scénario 4 : Contrôler l'accès au réseau public pour les pods dans un namespace à l'aide d'une network policy

Important

Cette opération peut affecter les services en ligne qui accèdent au réseau public. Nous vous recommandons d'effectuer les opérations suivantes dans un namespace vide.

Exécutez la commande suivante pour créer un namespace de test.
Créez un namespace nommé test-np.
```
kubectl create ns test-np
```
Sortie attendue :
```
namespace/test-np created
```

Exécutez la commande suivante pour créer une network policy par défaut pour le namespace qui autorise uniquement l'accès sortant aux réseaux privés.

vim default-deny.yaml

Voici un exemple de modèle pour le fichier 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

Vérifiez que le fichier default-deny.yaml a été créé.

kubectl apply -f default-deny.yaml

Sortie attendue :

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

Affichez la network policy :

kubectl get networkpolicy -n test-np

Sortie attendue :

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

Exécutez la commande suivante pour créer une network policy qui permet aux pods portant une étiquette spécifique d'accéder au réseau public.

vim allow-specify-label.yaml

Dans cet exemple, l'étiquette est 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.

Exécutez la commande suivante pour créer la network policy :

kubectl apply -f allow-specify-label.yaml

Sortie attendue :

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

Affichez la network policy :

kubectl get networkpolicy -n test-np

Sortie attendue :

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

Exécutez les commandes suivantes pour vérifier qu'un pod sans l'étiquette spéciale ne peut pas accéder au réseau public.
```
kubectl run -it --namespace test-np --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-intranet
```
```
ping aliyun.com
```
Sortie attendue :
```
PING aliyun.com (106.11.2xx.xxx): 56 data bytes
^C
--- aliyun.com ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
```
Le message 0 packets received indique que l'accès a échoué.

Remarque
L'accès a échoué car la network policy deny-public-net restreint par défaut l'accès au réseau public pour les pods dans le namespace test-np. Par conséquent, les pods démarrés dans ce namespace avec des étiquettes par défaut ne peuvent pas accéder au réseau public.

Exécutez la commande suivante pour vérifier qu'un pod portant l'étiquette public-network=true peut accéder au réseau public.

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

Sortie attendue :

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

Le message 0 % packet loss indique que le service a été accédé avec succès.

Remarque

L'accès a réussi car la network policy allow-public-network-for-labels autorise l'accès au réseau public pour les pods portant l'étiquette public-network=true. Par conséquent, le pod busybox-internet, qui porte cette étiquette, peut accéder au réseau public.