Je configure un espace de noms dans mon cluster kubernetes pour refuser tout appel réseau sortant tel que http://company.com a> mais pour permettre la communication inter-pod dans mon espace de noms, comme http: // my-nginx où my-nginx est un kubernetes service pointant vers mon pod nginx.
Comment y parvenir en utilisant la politique de réseau. La politique de réseau ci-dessous aide à bloquer tous les appels réseau sortants
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: deny-all-egress
namespace: sample
spec:
policyTypes:
- Egress
podSelector: {}
Comment mettre en liste blanche uniquement les appels inter-pod?
3 Réponses :
Je ne sais pas si vous pouvez le faire en utilisant Kubernetes NetworkPolicy, mais vous pouvez y parvenir avec des pods compatibles Istio.
Remarque: assurez-vous d'abord qu'Istio est installé sur votre cluster. Pour l'installation voir .
Voir la citation de la documentation d'Istio sur Egress Traffic .
Par défaut, les services compatibles Istio ne peuvent pas accéder aux URL extérieures du cluster car le pod utilise iptables pour rediriger de manière transparente tout le trafic sortant vers le proxy side-car, qui ne gère que destinations intra-cluster.
De plus, vous pouvez mettre sur liste blanche des domaines en dehors du cluster en ajoutant ServiceEntry et VirtualService à votre cluster, par exemple dans Configuration des services externes dans la documentation Istio.
J'espère que cela pourra vous être utile.
Cette citation a été modifiée dans la version 1.1. ce problème mentionne que
À l'aide des stratégies réseau, vous pouvez mettre sur liste blanche tous les pods dans un espace de noms:
- podSelector:
matchLabels:
role: nginx
Comme vous le savez probablement déjà, les pods auxquels au moins une stratégie réseau leur est appliquée ne peuvent communiquer qu'avec les cibles autorisées par tout La politique du réseau leur est appliquée.
Les noms n'ont pas vraiment d'importance. Les sélecteurs (namespaceSelector et podSelector dans ce cas) ne se soucient que des étiquettes. Les libellés sont des paires clé-valeur associées aux ressources. L'exemple ci-dessus suppose que l'espace de noms appelé sample a une étiquette de name=sample.
Si vous voulez mettre en liste blanche l'espace de noms appelé http: // my-nginx , vous devez d'abord ajouter une étiquette à votre espace de noms (s'il n'en a pas déjà un). name est une bonne clé IMO, et la valeur peut être le nom du service, http: // my-nginx dans ce cas particulier (je ne sais pas si : et / peuvent faire partie d'une étiquette). Ensuite, le simple fait de l'utiliser dans vos politiques réseau vous permettra de cibler l'espace de noms (pour l'entrée ou la sortie)
- namespaceSelector:
matchLabels:
name: http://my-nginx
Si vous souhaitez autoriser la communication avec un service appelé my-nginx , le nom du service n'a pas vraiment d'importance. Vous devez sélectionner les pods cibles à l'aide de podSelector, ce qui doit être fait avec le même libellé que le service utilise pour savoir quels pods lui appartiennent. Vérifiez votre service pour obtenir le libellé et utilisez la clé: valeur dans la stratégie réseau. Par exemple, pour une paire clé = valeur de role = nginx, vous devez utiliser
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-egress-to-sample
namespace: sample
spec:
policyTypes:
- Egress
podSelector: {}
egress:
- to:
- namespaceSelector:
matchLabels:
name: sample
Cela peut être fait en utilisant la combinaison suivante de stratégies réseau:
# The same as yours
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: deny-all-egress
namespace: sample
spec:
policyTypes:
- Egress
podSelector: {}
---
# allows connections to all pods in your namespace from all pods in your namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-namespace-egress
namespace: sample
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels: {}
---
# allows connections from all pods in your namespace to all pods in your namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-namespace-internal
namespace: sample
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels: {}
en supposant que la mise en œuvre de votre stratégie réseau implémente la spécification complète.
Cela permettra de réaliser la requête d'origine mais bloquera l'accès au service DNS Kubernetes (qui se trouve généralement dans l'espace de noms kube-system). Cela empêchera toutes les communications des pods dans l'espace de noms "sample". Détails ici: medium. com / @ reuvenharrison /…
@Mark c'est vrai, mais comme vous l'avez dit, ce n'était pas ce qui était demandé et toutes les charges de travail ne nécessitent pas un accès au DNS Kubernetes - l'accès au service DNS peut facilement être autorisé avec d'autres politiques
Avez-vous parcouru github.com/ahmetb/kubernetes-network-policy-recipes déjà?
Je vous remercie de le faire remarquer. Cet exemple particulier fonctionne pour moi github.com/ahmetb/kubernetes-network-policy-recipes/blob/master /… mais avec le hic que s'il y a un hôte avec le port 53 alors il n'arrêtera pas le appelez, n'est-ce pas?
Qu'entendez-vous par un hôte avec le port 53? Les services fonctionnent sur les ports. Il en résulterait que toute communication inter-pod sur le port 53 sera autorisée uniquement.