8.7. Configuration de la politique de réseau
En tant qu'administrateur de cluster ou de projet, vous pouvez configurer des politiques de réseau pour un projet.
8.7.1. A propos de la politique de réseau
Dans un cluster utilisant un plugin réseau qui prend en charge la politique réseau de Kubernetes, l'isolation du réseau est entièrement contrôlée par les objets NetworkPolicy
. Dans OpenShift Container Platform 4.12, OpenShift SDN prend en charge l'utilisation de la politique réseau dans son mode d'isolation réseau par défaut.
La politique de réseau ne s'applique pas à l'espace de noms du réseau hôte. Les pods dont le réseau d'hôtes est activé ne sont pas affectés par les règles de la politique de réseau.
Par défaut, tous les modules d'un projet sont accessibles aux autres modules et aux points d'extrémité du réseau. Pour isoler un ou plusieurs pods dans un projet, vous pouvez créer des objets NetworkPolicy
dans ce projet pour indiquer les connexions entrantes autorisées. Les administrateurs de projet peuvent créer et supprimer des objets NetworkPolicy
dans leur propre projet.
Si un pod est associé à des sélecteurs dans un ou plusieurs objets NetworkPolicy
, il n'acceptera que les connexions autorisées par au moins un de ces objets NetworkPolicy
. Un module qui n'est sélectionné par aucun objet NetworkPolicy
est entièrement accessible.
Les exemples suivants d'objets NetworkPolicy
illustrent la prise en charge de différents scénarios :
Refuser tout le trafic :
Pour qu'un projet soit refusé par défaut, ajoutez un objet
NetworkPolicy
qui correspond à tous les pods mais n'accepte aucun trafic :kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []
N'autoriser que les connexions provenant du contrôleur d'entrée de la plate-forme OpenShift Container :
Pour qu'un projet n'autorise que les connexions provenant du contrôleur d'ingestion de la plate-forme OpenShift Container, ajoutez l'objet
NetworkPolicy
suivant.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress
N'accepte que les connexions provenant de pods au sein d'un projet :
Pour que les pods acceptent les connexions d'autres pods du même projet, mais rejettent toutes les autres connexions de pods d'autres projets, ajoutez l'objet suivant
NetworkPolicy
:kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {}
N'autoriser le trafic HTTP et HTTPS qu'en fonction des étiquettes de pods :
Pour permettre uniquement l'accès HTTP et HTTPS aux pods avec un label spécifique (
role=frontend
dans l'exemple suivant), ajoutez un objetNetworkPolicy
similaire à ce qui suit :kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-http-and-https spec: podSelector: matchLabels: role: frontend ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443
Accepter les connexions en utilisant des sélecteurs d'espace de noms et de pods :
Pour faire correspondre le trafic réseau en combinant les sélecteurs d'espace de noms et de pods, vous pouvez utiliser un objet
NetworkPolicy
similaire à ce qui suit :kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-pod-and-namespace-both spec: podSelector: matchLabels: name: test-pods ingress: - from: - namespaceSelector: matchLabels: project: project_name podSelector: matchLabels: name: test-pods
NetworkPolicy
sont additifs, ce qui signifie que vous pouvez combiner plusieurs objets NetworkPolicy
pour répondre à des exigences complexes en matière de réseau.
Par exemple, pour les objets NetworkPolicy
définis dans les exemples précédents, vous pouvez définir les politiques allow-same-namespace
et allow-http-and-https
dans le même projet. Cela permet aux pods portant l'étiquette role=frontend
d'accepter toutes les connexions autorisées par chaque politique. C'est-à-dire des connexions sur n'importe quel port à partir de pods dans le même espace de noms, et des connexions sur les ports 80
et 443
à partir de pods dans n'importe quel espace de noms.
8.7.1.1. Utilisation de la stratégie réseau allow-from-router
Utilisez l'adresse NetworkPolicy
pour autoriser le trafic externe quelle que soit la configuration du routeur :
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-router
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/ingress:""1
podSelector: {}
policyTypes:
- Ingress
- 1
policy-group.network.openshift.io/ingress:""
prend en charge à la fois Openshift-SDN et OVN-Kubernetes.
8.7.1.2. Utilisation de la stratégie réseau allow-from-hostnetwork
Ajoutez l'objet suivant allow-from-hostnetwork
NetworkPolicy
pour diriger le trafic des pods du réseau hôte :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-hostnetwork spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/host-network:"" podSelector: {} policyTypes: - Ingress
8.7.2. Exemple d'objet NetworkPolicy
Un exemple d'objet NetworkPolicy est annoté ci-dessous :
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-27107 1 spec: podSelector: 2 matchLabels: app: mongodb ingress: - from: - podSelector: 3 matchLabels: app: app ports: 4 - protocol: TCP port: 27017
- 1
- Le nom de l'objet NetworkPolicy.
- 2
- Un sélecteur qui décrit les pods auxquels la politique s'applique. L'objet de politique ne peut sélectionner que des pods dans le projet qui définit l'objet NetworkPolicy.
- 3
- Un sélecteur qui correspond aux pods à partir desquels l'objet de politique autorise le trafic entrant. Le sélecteur correspond aux pods situés dans le même espace de noms que la NetworkPolicy.
- 4
- Liste d'un ou plusieurs ports de destination sur lesquels le trafic doit être accepté.
8.7.3. Création d'une politique de réseau à l'aide de l'interface de ligne de commande
Pour définir des règles granulaires décrivant le trafic réseau entrant ou sortant autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie réseau.
Si vous vous connectez avec un utilisateur ayant le rôle cluster-admin
, vous pouvez créer une stratégie de réseau dans n'importe quel espace de noms du cluster.
Conditions préalables
-
Votre cluster utilise un plugin réseau qui prend en charge les objets
NetworkPolicy
, tel que le fournisseur de réseau OpenShift SDN avecmode: NetworkPolicy
. Ce mode est le mode par défaut pour OpenShift SDN. -
Vous avez installé l'OpenShift CLI (
oc
). -
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges
admin
. - Vous travaillez dans l'espace de noms auquel s'applique la politique de réseau.
Procédure
Créer une règle de politique :
Créer un fichier
<policy_name>.yaml
:$ touch <policy_name>.yaml
où :
<policy_name>
- Spécifie le nom du fichier de stratégie réseau.
Définissez une politique de réseau dans le fichier que vous venez de créer, comme dans les exemples suivants :
Refuser l'entrée de tous les pods dans tous les espaces de noms
Il s'agit d'une politique fondamentale, qui bloque tout réseau inter-pods autre que le trafic inter-pods autorisé par la configuration d'autres politiques de réseau.
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: ingress: []
Autoriser l'entrée de tous les pods dans le même espace de noms
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {}
Autoriser le trafic entrant vers un pod à partir d'un espace de noms particulier
Cette politique autorise le trafic vers les pods étiquetés
pod-a
à partir des pods fonctionnant surnamespace-y
.kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-traffic-pod spec: podSelector: matchLabels: pod: pod-a policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: namespace-y
Pour créer l'objet de stratégie de réseau, entrez la commande suivante :
oc apply -f <policy_name>.yaml -n <namespace>
où :
<policy_name>
- Spécifie le nom du fichier de stratégie réseau.
<namespace>
- Facultatif : Spécifie l'espace de noms si l'objet est défini dans un espace de noms différent de l'espace de noms actuel.
Exemple de sortie
networkpolicy.networking.k8s.io/deny-by-default created
Si vous vous connectez à la console web avec les privilèges cluster-admin
, vous avez le choix de créer une politique de réseau dans n'importe quel espace de noms du cluster directement dans YAML ou à partir d'un formulaire dans la console web.
8.7.4. Configuration de l'isolation des multitenants à l'aide d'une stratégie de réseau
Vous pouvez configurer votre projet pour l'isoler des pods et des services dans d'autres espaces de noms de projets.
Conditions préalables
-
Votre cluster utilise un plugin réseau qui prend en charge les objets
NetworkPolicy
, tel que le fournisseur de réseau OpenShift SDN avecmode: NetworkPolicy
. Ce mode est le mode par défaut pour OpenShift SDN. -
You installed the OpenShift CLI (
oc
). -
Vous êtes connecté au cluster avec un utilisateur disposant des privilèges
admin
.
Procédure
Créez les objets
NetworkPolicy
suivants :Une police nommée
allow-from-openshift-ingress
.$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress EOF
Notepolicy-group.network.openshift.io/ingress: ""
est l'étiquette de sélecteur d'espace de noms préférée pour OpenShift SDN. Vous pouvez utiliser l'étiquette de sélecteur d'espace de nomsnetwork.openshift.io/policy-group: ingress
, mais il s'agit d'une étiquette héritée.Une police nommée
allow-from-openshift-monitoring
:$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: monitoring podSelector: {} policyTypes: - Ingress EOF
Une police nommée
allow-same-namespace
:$ cat << EOF| oc create -f - kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {} EOF
Une police nommée
allow-from-kube-apiserver-operator
:$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress EOF
Pour plus de détails, voir Nouveau contrôleur de webhook
kube-apiserver-operator
validant l'état de santé du webhook.
Facultatif : Pour confirmer que les politiques de réseau existent dans votre projet actuel, entrez la commande suivante :
$ oc describe networkpolicy
Exemple de sortie
Name: allow-from-openshift-ingress Namespace: example1 Created on: 2020-06-09 00:28:17 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: ingress Not affecting egress traffic Policy Types: Ingress Name: allow-from-openshift-monitoring Namespace: example1 Created on: 2020-06-09 00:29:57 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: monitoring Not affecting egress traffic Policy Types: Ingress
8.7.5. Créer des politiques de réseau par défaut pour un nouveau projet
En tant qu'administrateur de cluster, vous pouvez modifier le modèle de nouveau projet pour inclure automatiquement les objets NetworkPolicy
lorsque vous créez un nouveau projet.
8.7.6. Modifier le modèle pour les nouveaux projets
En tant qu'administrateur de cluster, vous pouvez modifier le modèle de projet par défaut afin que les nouveaux projets soient créés en fonction de vos besoins.
Pour créer votre propre modèle de projet personnalisé :
Procédure
-
Connectez-vous en tant qu'utilisateur disposant des privilèges
cluster-admin
. Générer le modèle de projet par défaut :
oc adm create-bootstrap-project-template -o yaml > template.yaml
-
Utilisez un éditeur de texte pour modifier le fichier
template.yaml
généré en ajoutant des objets ou en modifiant des objets existants. Le modèle de projet doit être créé dans l'espace de noms
openshift-config
. Chargez votre modèle modifié :$ oc create -f template.yaml -n openshift-config
Modifiez la ressource de configuration du projet à l'aide de la console Web ou de la CLI.
En utilisant la console web :
-
Naviguez jusqu'à la page Administration
Cluster Settings. - Cliquez sur Configuration pour afficher toutes les ressources de configuration.
- Trouvez l'entrée pour Project et cliquez sur Edit YAML.
-
Naviguez jusqu'à la page Administration
Utilisation de la CLI :
Modifier la ressource
project.config.openshift.io/cluster
:$ oc edit project.config.openshift.io/cluster
Mettez à jour la section
spec
pour inclure les paramètresprojectRequestTemplate
etname
, et définissez le nom de votre modèle de projet téléchargé. Le nom par défaut estproject-request
.Ressource de configuration de projet avec modèle de projet personnalisé
apiVersion: config.openshift.io/v1 kind: Project metadata: ... spec: projectRequestTemplate: name: <template_name>
- Après avoir enregistré vos modifications, créez un nouveau projet pour vérifier que vos modifications ont bien été appliquées.
8.7.6.1. Ajouter des politiques de réseau au nouveau modèle de projet
En tant qu'administrateur de cluster, vous pouvez ajouter des politiques de réseau au modèle par défaut pour les nouveaux projets. OpenShift Container Platform créera automatiquement tous les objets NetworkPolicy
spécifiés dans le modèle du projet.
Conditions préalables
-
Votre cluster utilise un fournisseur de réseau CNI par défaut qui prend en charge les objets
NetworkPolicy
, tel que le fournisseur de réseau OpenShift SDN avec l'optionmode: NetworkPolicy
. Ce mode est le mode par défaut pour OpenShift SDN. -
You installed the OpenShift CLI (
oc
). -
Vous devez vous connecter au cluster avec un utilisateur disposant des privilèges
cluster-admin
. - Vous devez avoir créé un modèle de projet personnalisé par défaut pour les nouveaux projets.
Procédure
Modifiez le modèle par défaut pour un nouveau projet en exécutant la commande suivante :
$ oc edit template <project_template> -n openshift-config
Remplacez
<project_template>
par le nom du modèle par défaut que vous avez configuré pour votre cluster. Le nom du modèle par défaut estproject-request
.Dans le modèle, ajoutez chaque objet
NetworkPolicy
en tant qu'élément du paramètreobjects
. Le paramètreobjects
accepte une collection d'un ou plusieurs objets.Dans l'exemple suivant, la collection de paramètres
objects
comprend plusieurs objetsNetworkPolicy
.objects: - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {} - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress ...
Facultatif : Créez un nouveau projet pour confirmer que vos objets de stratégie de réseau ont été créés avec succès en exécutant les commandes suivantes :
Créer un nouveau projet :
oc new-project <projet> $ oc new-project <projet> 1
- 1
- Remplacez
<project>
par le nom du projet que vous créez.
Confirmez que les objets de stratégie de réseau du nouveau modèle de projet existent dans le nouveau projet :
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s