Déployer Dynamic Engine avec les politiques de réseau par défaut

Activez les politiques de réseau par défaut pour le chart Dynamic Engine et le chart d'environnement Dynamic Engine lors de l'installation ou d'une mise à niveau pour contrôler le trafic entre le chart Dynamic Engine, le chart d'environnement et les services externes.

Après avoir configuré les politiques par défaut, vous pouvez suivre les scénarios de personnalisation avancée associés pour définir des règles de sortie personnalisées.

Avant de commencer

Les définitions des ressources personnalisées dynamic-engine-crd doivent avoir été installées à l'aide du chart Helm oci://ghcr.io/talend/helm/dynamic-engine-crd. Si ce n'est pas le cas, exécutez les commandes suivantes pour l'installation :
1. Trouvez la version du chart à utiliser :
  - Exécutez la commande Helm suivante :
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
  - Visualisez la version directement depuis Talend Management Console ou consultez le Dynamic Engine journal de modification de la version du chart dans votre version de Dynamic Engine.
  - Utilisez un appel d'API pour l'endpoint de version de Dynamic Engine (en anglais).
2. Exécutez la commande suivante pour installer le chart Helm dans une version donnée :
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  Remplacez <helm_chart_version> par la version du chart supportée par votre version du Dynamic Engine.
  Si vous ne spécifiez pas la version, vous installez la dernière version disponible du chart dynamic-engine-crd.
Le cluster Kubernetes doit utiliser un plug-in de réseau qui supporte l'application de politiques de réseau. Pour plus d'informations sur Kubernetes Network Policies, consultez Politiques de réseau (en anglais).

Pourquoi et quand exécuter cette tâche

Cette procédure s'applique aux clusters standards et aux modes Kubernetes gérés, à condition que le plug-in CNI du cluster applique les ressources Kubernetes NetworkPolicy. Vous pouvez l'appliquer lors de l'installation initiale ou d'une mise à niveau.

L'ensemble de politiques de réseau par défaut vous fournit une base de référence par défaut pour la sécurité des déploiements Dynamic Engine. Pour le contrôle en sortie personnalisé, consultez Limiter la sortie aux adresses IP connues et Autoriser la sortie générale avec des restrictions internes.

Le support de Kubernetes Network Policies a été lancé dans Dynamic Engine v1.6.0.

Procédure

Définissez les variables de déploiement de l'exemple.

export DYNAMIC_ENGINE_VERSION=1.6.0
export DYNAMIC_ENGINE_ID=c-m-sjufu4qy
export DYNAMIC_ENGINE_ENVIRONMENT_ID=684c3baec6a6f88f61e9d59d

Remplacez les valeurs de l'exemple par les informations de votre moteur.

Installez et mettez à niveau les charts Dynamic Engine et d'environnement avec l'ensemble de politiques intégré.

cat <<EOF > custom-network-policies-values.yaml
configuration:
  networkPolicies:
    enabled: true
EOF

helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
  -f $DYNAMIC_ENGINE_ID-values.yaml \
  -f custom-network-policies-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine \
  --version $DYNAMIC_ENGINE_VERSION

helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
  -f custom-network-policies-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version $DYNAMIC_ENGINE_VERSION

Cela applique les politiques par défaut à l'instance de Dynamic Engine et à son environnement.

Vérifiez que les politiques ont été créées.

kubectl get networkpolicies -A -l "app.qlik.com/owned-by=qlik"

La sortie doit afficher les politiques d'autorisation et de refus par défaut dans les espaces de noms du moteur et de l'environnement.

NAMESPACE                                      NAME                                     POD-SELECTOR                                           AGE
qlik-processing-env-684c3baec6a6f88f61e9d59d   default-allow-dns                        <none>                                                 56m
qlik-processing-env-684c3baec6a6f88f61e9d59d   default-allow-egress-to-internet         <none>                                                 56m
qlik-processing-env-684c3baec6a6f88f61e9d59d   default-allow-egress-to-same-namespace   <none>                                                 56m
qlik-processing-env-684c3baec6a6f88f61e9d59d   default-deny-all                         <none>                                                 56m
qlik-dynamic-engine                            default-allow-dns                        <none>                                                 4s
qlik-dynamic-engine                            default-allow-egress-to-internet         app.kubernetes.io/name in (engine-operator,reloader)   4s
qlik-dynamic-engine                            default-allow-ingress-docker-registry    app=docker-registry                                    4s
qlik-dynamic-engine                            default-deny-all                         <none>                                                 4s

Comme indiqué dans cette sortie, les politiques de réseau sont délimitées par les espaces de noms du moteur et de ses environnements. Chaque espace de noms a ses propres politiques de réseau.

Résultats

L'instance de Dynamic Engine et son environnement s'exécutent maintenant avec les politiques de réseau par défaut. Dans Talend Management Console, l'environnement doit avoir le statut Ready (Prêt) si les politiques autorisent le trafic requis.

Les politiques de réseau par défaut de Dynamic Engine sont suffisantes pour la plupart des besoins de renforcement du contrôle de l'accès au réseau des pods. Si vous avez besoin de règles de sortie personnalisées, consultez Restreindre la sortie aux adresses IP connues pour le Dynamic Engine ou Autoriser la sortie générale avec des restrictions internes pour Dynamic Engine.

Résolution de problèmes :

Si des pods s'exécutent, mais qu'ils échouent aux contrôles d'intégrité ou ne parviennent pas à communiquer, cela signifie que les politiques sont probablement trop restrictives.

Vérifiez les politiques de chaque espace de noms avec kubectl get networkpolicies -n <espace de noms> -o yaml.
Vérifiez les logs des pods pour voir les erreurs de connexion.
Désactivez temporairement les politiques de manière déclarative pour vérifier la connectivité via helm upgrade et --set configuration.networkPolicies.enabled=false. Évitez de supprimer directement des ressources NetworkPolicy gérées par Helm.
Vérifiez que le cluster utilise un plug-in CNI qui applique des politiques de réseau.

Les échecs de résolution de DNS signifient souvent que le service kube-dns est bloqué.

Vérifiez que la politique default-allow-dns est activée.
Confirmez que la politique autorise la sortie vers le port 53.
Si le DNS continue d'échouer, ajoutez une règle qui autorise la sortie vers l'espace de noms kube-system sur le port UDP 53.

Les problèmes de connectivité de services externes signifient généralement qu'il manque une règle de sortie pour un endpoint ou un port requis.

Vérifiez les adresses IP via dig.
Testez la connectivité de l'intérieur d'un pod via kubectl exec et curl -I https://api.us.cloud.talend.com.
Vérifiez que le serveur d'API Kubernetes reste accessible sur le port 443 ou 8443.

Si les pods ne parviennent pas à extraire des images, cela signifie probablement qu'il manque la règle de sortie du registre ou qu'elle pointe vers le mauvais registre.

Si vous utilisez le registre intégré, vérifiez que la politique d'environnement autorise la sortie vers le service docker-registry.
Si vous utilisez un registre externe, ajoutez une règle de sortie pour son adresse IP et son port.
Vérifiez que le service de registres fonctionne et qu'il est accessible depuis le cluster.

Si des politiques de réseau sont créées, mais que les pods continuent de communiquer librement, il se peut que le plug-in du réseau n'applique pas les politiques.

Vérifiez que le cluster utilise Calico, Cilium, Weave ou une autre CNI supportant les politiques de réseau.
Vérifiez que les politiques sont créées dans les espaces de noms corrects.
Inspectez les pods du contrôleur de réseau dans l'espace de noms kube-system.

Les commandes de débogage utiles incluent

# View all network policies
kubectl get networkpolicies -A

# Describe a specific policy
kubectl describe networkpolicy <policy-name> -n <namespace>

# Check pod connectivity
kubectl exec <pod-name> -n <namespace> -- ping <target-pod-ip>

# Test DNS from a pod
kubectl exec <pod-name> -n <namespace> -- nslookup <service-name>

# Check pod labels (used by policies)
kubectl get pods -n <namespace> --show-labels

# Test external connectivity
kubectl exec <pod-name> -n <namespace> -- curl -I https://<external-url>

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – faites-le-nous savoir.

Laissez vos commentaires ici