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

Activez la stratégie réseau dans les clusters ACK Serverless pour contrôler le trafic au niveau des pods avec le module complémentaire Poseidon.

Prérequis

Un cluster géré ACK ou un cluster dédié ACK a été créé. Consultez les rubriques Créer un cluster géré ACK ou Créer un cluster dédié ACK (Obsolète).
Important
Dans les clusters ACK managed cluster Pro et ACK Serverless Pro, la stratégie réseau est mise en œuvre par différents modules complémentaires.
- Dans un cluster géré ACK Pro (pour les nœuds qui ne sont pas des instances de conteneur élastique), la stratégie réseau est mise en œuvre par le plugin réseau Terway. Consultez la rubrique Activer la stratégie réseau dans les clusters ACK.
- Dans les instances de conteneur élastique (ECI) des clusters ACK Serverless et des clusters gérés ACK Pro, la stratégie réseau est mise en œuvre par le module complémentaire Poseidon.
Le module complémentaire ACK Virtual Node est mis à jour 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

La stratégie réseau est prise en charge uniquement dans les clusters ACK Serverless Pro et ACK managed cluster Pro.
La stratégie réseau 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 la stratégie réseau

Installez le module complémentaire Poseidon pour activer la stratégie réseau 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 Add-ons, cliquez sur l'onglet Networking. Sur la carte Poseidon, cliquez sur Install.
4. Dans la boîte de dialogue Install Poseidon, sélectionnez Enable NetworkPolicy for ACS/ECI instances et cliquez sur OK.
  
  Une fois l'installation terminée, le statut 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 options. 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 options. 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. Sous l'onglet Pods, localisez le pod busybox-{hash value} et cliquez sur Terminal dans la colonne Actions.
3. Dans le terminal en ligne de commande busybox, exécutez la commande wget nginx pour tester l'accès à Nginx.
  
  Le résultat 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

Résultat attendu :

pod/nginx created

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

kubectl get pod

Résultat attendu :

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

Créez un Service nommé nginx :

kubectl expose pod nginx --port=80

Résultat attendu :

service/nginx exposed

Consultez le Service :

kubectl get service

Résultat attendu :

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

Résultat attendu :

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.

Résultat attendu :

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 stratégie réseau

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 au service aux applications disposant d'étiquettes spécifiques à l'aide d'une stratégie réseau

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 stratégie réseau à partir du fichier policy.yaml.
```
kubectl apply -f policy.yaml 
```
Résultat attendu :
```
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 demande expire.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Testez l'accès au Service nginx :
```
wget nginx
```
Résultat attendu :
```
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

Résultat attendu :

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

Le résultat indique que la progression de la connexion est de 100 %. Cela signifie que la demande 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 stratégie réseau

Exécutez la commande suivante pour créer une instance SLB Alibaba Cloud pour l'application nginx. Spécifiez type=LoadBalancer pour exposer le Service nginx sur 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 stratégie réseau à partir du fichier nginx-service.yaml.

kubectl apply -f nginx-service.yaml

Résultat attendu :

service/nginx-slb created

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

kubectl get service nginx-slb

Résultat attendu :

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
```
Résultat attendu :
```
--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é n'est accessible qu'aux applications disposant de 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 consistant à restreindre l'accès au service aux applications disposant d'étiquettes spécifiques.
Solution : Modifiez la stratégie réseau pour ajouter le bloc CIDR source autorisé.

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

curl myip.ipip.net

Résultat attendu :

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 stratégie réseau à partir du fichier policy.yaml.
```
kubectl apply -f policy.yaml 
```
Résultat attendu :
```
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 vérification de l'état 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
```
Résultat attendu :
```
Connecting to 47.110.XX.XX (47.110.XX.XX:80)
index.html           100% |***********************************************************|   612  0:00:00 ETA
```
Le résultat 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 à une adresse spécifiée uniquement à l'aide d'une stratégie réseau

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

Résultat attendu :

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 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 stratégie réseau à partir du fichier busybox-policy.yaml.
```
kubectl apply -f busybox-policy.yaml 
```
Résultat attendu :
```
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
```
Résultat attendu :
```
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

Résultat attendu :

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

Le résultat indique que la progression de la connexion est de 100 %. Cela signifie que le service a été consulté 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 stratégie réseau

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
```
Résultat attendu :
```
namespace/test-np created
```

Exécutez la commande suivante pour créer une stratégie réseau 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

Résultat attendu :

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

Consultez la stratégie réseau :

kubectl get networkpolicy -n test-np

Résultat attendu :

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

Exécutez la commande suivante pour créer une stratégie réseau qui permet aux pods disposant d'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 stratégie réseau :

kubectl apply -f allow-specify-label.yaml

Résultat attendu :

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

Consultez la stratégie réseau :

kubectl get networkpolicy -n test-np

Résultat attendu :

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
```
Résultat attendu :
```
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 stratégie réseau deny-public-net restreint par défaut l'accès au réseau public pour les pods du 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 avec 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

Résultat attendu :

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é consulté avec succès.

Remarque

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