Règles réseau Calico et Kubernetes par défaut

Lorsqu'un cluster avec un réseau local virtuel (VLAN) public est créé, une ressource HostEndpoint avec le libellé ibm.role: worker_public est générée automatiquement pour chaque noeud worker et l'interface réseau publique associée. CetteHostEndpoint entraîne la suppression de tout le trafic vers ou depuis l'interface de réseau public, sauf si elle est spécifiquement autorisée par une règle Calico qui sélectionne le labelibm.role: worker_public.

Une ressource HostEndpoint avec le libellé ibm.role: worker_private est également automatiquement créée pour chaque noeud worker et l'interface réseau privée associée. Une règle allow-all-private-defaultpar défaut est créée de sorte que tout le trafic soit autorisé à partir de l'interface de réseau privé. Cela HostEndpoint permet aux utilisateurs de clusters de restreindre plus facilement le trafic sur le réseau privé en créant des politiques Calico qui sélectionnent ibm.role: worker_private et dont le numéro d'ordre est inférieur à celui de la allow-all-private-default.

Ces règles d'hôte Calico par défaut permettent à l'ensemble du trafic réseau public sortant et autorisent le trafic entrant public à des composants de cluster spécifiques, tels que les services Kubernetes NodePort, LoadBalancer et Ingress. Tout le trafic privé est autorisé par défaut par la règle allow-all-private-default. Tout autre trafic de réseau entrant à partir d'Internet vers vos nœuds worker qui n'est pas spécifié dans les règles par défaut est bloqué. Les règles par défaut n'affectent pas le trafic entre les pods.

Ne supprimez pas les politiques par défaut de votre cluster, car elles seront recréées lors du prochain rafraîchissement ou de la prochaine mise à jour du maître du cluster. Si vous souhaitez restreindre davantage le trafic, appliquez des règles Calico d'ordre inférieur pour bloquer le trafic. Assurez-vous de bien comprendre ce que vous bloquez et que les composants du cluster n'ont pas besoin du trafic que vous souhaitez bloquer.

Consultez les règles d'hôte Calico par défaut suivantes qui sont automatiquement appliquées à votre cluster.

Des politiques d' Kubernetes par défaut limitant l'accès au tableau de bord d' Kubernetes sont également créées. Les règles Kubernetes ne s'appliquent pas au noeud final d'hôte, mais au niveau du pod et à tous les clusters classiques et VPC.

Affichage des règles réseau

Affichez les détails des règles réseau par défaut ou ayant été ajoutées qui sont appliquées à votre cluster.

Avant de commencer, installez et configurez l'interface de ligne de commande (CLI) d' Calico, puis définissez le contexte de votre cluster pour pouvoir exécuter les commandes Calico.

1. Examinez le noeud final d'hôte Calico.

   kubectl get hostendpoints.projectcalico.org -o yaml
   

2. Affichez toutes les règles de réseau Calico qui ont été créées pour le cluster. Cette liste inclut des règles qui ne s'appliquent pas encore aux pods ou aux hôtes. Pour qu'une règle Calico soit appliquée, un pod Kubernetes ou CalicoHostEndpoint doit exister et correspondre au sélecteur qui se trouve dans la stratégie de réseau Calico.

   Calico Les politiques réseau s'appliquent à des espaces de noms spécifiques :

   kubectl get networkpolicy.projectcalico.org --all-namespaces -o wide
   

   Kubernetes Les politiques réseau s'appliquent également à des espaces de noms spécifiques :

   kubectl get networkpolicies.networking.k8s.io --all-namespaces -o wide
   

   Calico Les politiques de réseau globales ne s'appliquent pas à des espaces de noms spécifiques :

   kubectl get globalnetworkpolicies.projectcalico.org -o wide
   

3. Afficher les détails d'une politique de réseau Calico.

   kubectl get networkpolicies.projectcalico.org -o yaml <policy_name> --namespace <policy_namespace>
   

4. Afficher les détails de toutes les politiques du réseau mondial d' Calico s pour le cluster.

   kubectl get globalnetworkpolicies.projectcalico.org -o yaml
   

5. Afficher les détails de toutes les politiques réseau d' Kubernetes s pour le cluster.

   kubectl get networkpolicies.networking.k8s.io --all-namespaces -o yaml
   

Ajout de règles réseau

Généralement, les règles par défaut ne nécessitent pas de modifications. Seuls les scénarios avancés peuvent nécessiter des modifications. Si vous constatez que vous devez apporter des modifications, vous pouvez créer vos propres règles réseau.

Pour créer des politiques réseau d Kubernetes, consultez la documentation relative aux politiques réseau d' Kubernetes.

Pour créer des règles Calico, procédez comme indiqué ci-après.

1. Définissez votre politique de réseauCalico ou votre politique de réseau globale en créant un script de configuration (.yaml) utilisant la syntaxe de la politique Calico v3. Ces fichiers de configuration incluent les sélecteurs qui décrivent les pods, les espaces de noms ou les hôtes, auxquels s'appliquent ces règles.

2. Appliquez les règles au cluster.

   kubectl apply -f policy.yaml
   

Calico De plus, les politiques réseau d' Kubernetes e bloquent uniquement les nouvelles connexions; elles n'interrompent pas les connexions qui existaient avant l'application de la politique. Après avoir appliqué une nouvelle politique ou une politique modifiée, procédez comme suit pour vérifier qu'elle fonctionne correctement et qu'elle ne bloque pas plus qu'elle ne le devrait :

1. Redémarrez tous les pods susceptibles d'être affectés par la politique, ou redémarrez tous les pods si votre sélecteur n'est pas correct et que cela affecte davantage de pods que prévu.

2. Exécutez ibmcloud ks cluster master refresh -c CLUSTER-IDpour redémarrer vos pods maître de cluster. Cela interrompt les connexions existantes entre kubelet et d'autres composants et le maître, et les oblige à se reconnecter. Cela permet de vérifier si les politiques nouvelles ou modifiées bloquent des connexions nécessaires à vos composants principaux.

3. Essayez de vous connecter au tableau de bord d' Kubernetes s pour vous assurer que les modifications apportées aux règles ne bloquent pas les connexions requises par ces composants.

Contrôle du trafic entrant vers les services d'équilibreur de charge de réseau ou NodePort

Les services par défaut, Kubernetes NodePort et l'équilibreur de charge rendent votre application disponible sur toutes les interfaces de cluster publiques et privées. Vous pouvez toutefois utiliser des règles Calico pour bloquer le trafic entrant vers vos services en fonction de l'origine ou de la destination du trafic.

Les règles Kubernetes et Calico par défaut sont difficiles à appliquer pour protéger les services de Kubernetes NodePort et LoadBalancer en raison des règles DNAT Iptables générées pour ces services. Cependant, les règles pré-DNAT empêchent le trafic spécifié d'atteindre vos applications car elles génèrent et appliquent des règles Iptables avant que Kubernetes utilise la fonction DNAT standard pour transférer le trafic vers les pods.

Quelques utilisations classiques des règles réseau pré-DNAT Calico :

• Blocage du trafic vers les ports de noeud publics d'un service d'équilibreur de charge de réseau privé (NLB) : un service d'équilibreur de charge de réseau rend votre application accessible via l'adresse IP et le port de l'équilibreur de charge de réseau et la rend également accessible via les ports de noeud du service. Les ports de noeud sont accessibles sur toutes les adresses IP (publiques et privées) pour tous les noeuds figurant dans le cluster.
• Blocage du trafic vers les ports de noeud publics sur les clusters qui exécutent des noeuds worker de périphérie : le blocage des ports de noeud garantit que les noeuds worker de périphérie sont les seuls noeuds worker qui traitent le trafic entrant.
• Blocage du trafic en provenance de certaines adresses IP source ou routages CIDR
• Autorisation du trafic provenant uniquement de certaines adresses IP source ou de certains routages CIDR et blocage de tout autre trafic

Pour voir comment autoriser ou bloquer des adresses IP source, essayez le tutoriel sur l'utilisation des règles réseau Calico pour bloquer le trafic.

Exemple de règles Calico pour restreindre le trafic réseau public ou privé

IBM Fournit un ensemble d'exemples de politiques de réseau public Calico et de politiques de réseau privé Calico qui restreignent davantage le trafic des réseaux public et privé sur les nœuds de travail du cluster.

Ces politiques ne sont pas destinées à tout bloquer, et ne satisfassent pas nécessairement les exigences de conformité. Ils ne bénéficient pas d'un support actif de la part d' IBM, sont uniquement destinés à servir de point de départ et doivent être adaptés à vos cas d'utilisation spécifiques. Pour plus d'informations, voir le fichier README.

IBM Il n'est plus recommandé d'utiliser les exemples de politiques allow-egress-pods-public, allow-public-services-pods, allow-egress-pods-private ou allow-private-services-pods figurant dans les sections Application des politiques de réseau public et Application des politiques de réseau privé. Ces politiques contrôlent les sorties de tous les pods du cluster. Pour contrôler le trafic entrant et sortant des pods, IBM recommande d’utiliser Kubernetes NetworkPolicy et de cibler des espaces de noms et des pods spécifiques, plutôt que d’utiliser ces politiques générales qui traitent chaque pod de la même manière.

Contrôle du trafic entre les pods

Les règles Kubernetes protègent les pods du trafic réseau interne. Vous pouvez créer des règles de réseau de Kubernetes simple pour isoler les micro-services d'application l'un de l'autre dans un espace de nom ou dans des espaces de nom.

Par défaut, un pod, quel qu'il soit, a accès à n'importe quel autre pod présent dans le cluster. En outre, un pod, quel qu'il soit, a accès à n'importe quel service qui est exposé par le réseau de pods, par exemple, un service de métriques, le DNS de cluster, le serveur d'API ou les services que vous créez manuellement dans votre cluster.

Journalisation du trafic refusé

Pour consigner les demandes de trafic refusé sur certains pods de votre cluster, vous pouvez créer une règle réseau de journalisation Calico.

Lorsque vous configurez des règles réseau pour limiter le trafic sur les pods d'application, les demandes de trafic qui ne sont pas autorisées par ces règles sont refusées et supprimées. Dans certains cas, vous souhaiterez obtenir plus d'informations sur les demandes de trafic refusé. Par exemple, vous pouvez éventuellement détecter un trafic inhabituel qui est systématiquement refusé par l'une de vos règles réseau. Pour surveiller cette menace de sécurité potentielle, vous pouvez configurer la journalisation de sorte à enregistrer toutes les fois qu'une règle refuse une action intentée sur les pods d'application indiqués.

Cette section vous montre comment consigner du trafic qui est rejeté par une règle de réseau Kubernetes. Pour consigner du trafic rejeté par une règle réseau Calico, voir la leçon 5 du tutoriel sur les règles réseau Calico.

1. Créez ou utilisez une règle de réseau Kubernetes existante pour bloquer ou limiter le trafic entrant.

   1. Créez une règle de réseau Kubernetes. Par exemple, pour contrôler le trafic entre les pods, vous pouvez utiliser l'exemple de règle Kubernetes nommée access-nginx qui limite l'accès à une application NGINX. Le trafic entrant dans les pods avec le libellé "run=nginx" est autorisé uniquement en provenance des pods avec le libellé "run=access". Tout autre trafic entrant vers les pods d'application "run=nginx" est bloqué.

       kind: NetworkPolicy
       apiVersion: networking.k8s.io/v1
       metadata:
        name: access-nginx
       spec:
        podSelector:
          matchLabels:
            run: nginx
        ingress:
          - from:
            - podSelector:
                matchLabels:
                  run: access
       ```
   2. Appliquez la politique.
   
   ```sh {: pre}
       kubectl apply -f <policy_name>.yaml
       ```
   

2. Pour consigner tout le trafic refusé par la règle que vous avez créée précédemment, créez une règle réseau Calico nommée log-denied-packets. La politique suivante Calico utilise le même sélecteur de pod que la politique d’exemple Kubernetesaccess-nginx décrite à l’étape 1, mais la syntaxe est légèrement différente puisqu’il s’agit d’un Calico NetworkPolicy au lieu d’un Kubernetes NetworkPolicy. De plus, comme toutes les NetworkPolicy Kubernetes sont évaluées par Calico en tant que commande 1000, le numéro de commande 3000 est ajouté pour s'assurer qu'il est évalué après la NetworkPolicy Kubernetes. Avec ces deux politiques en place, voici le résultat :

   • Les nouvelles connexions entrant dans le pod nginx sont d'abord évaluées par rapport à la stratégie NetworkPolicy de Kubernetes (ordre1000). Les connexions provenant d’un pod portant le label run=access sont immédiatement acceptées, ce qui signifie qu’aucune autre politique n’est évaluée.
   • Si la connexion provient d’un pod ne portant pas le label run=access (ou de tout autre élément qui n’est pas un pod), la commande Kubernetes NetworkPolicy n’aura aucun effet et Calico évaluera ensuite la politique log-denied-packets. Cette règle consigne le paquet dans syslog sur le noeud worker sur le pod nginx.
   • Calico vérifie ensuite que d'autres règles s'appliquent à la connexion et, comme il n'en trouve aucune, le paquet est alors supprimé. En effet, tout trafic vers une pod avec une règle qui n'est pas explicitement autorisée est supprimé.

       apiVersion: projectcalico.org/v3
       kind: NetworkPolicy
       metadata:
         name: log-denied-packets
       spec:
         types:
         - Ingress
         ingress:
         - action: Log
           destination: {}
           source: {}
         selector: projectcalico.org/orchestrator == 'k8s' && run == 'nginx'
         order: 3000
       ```
   
   

types

Cette règle Ingress s'applique à toute les demandes de trafic entrant. La valeur Ingress est un terme général désignant tout trafic entrant et ne se réfère pas au trafic provenant uniquement de l'équilibreur de charge d'application (ALB) Ingress d'IBM. ingress : action: Cette action Log enregistre une entrée de journal pour toutes les requêtes correspondant à cette politique dans le chemin /var/log/syslog d'accès sur le nœud de travail. : destination: Aucune destination n'est spécifiée car selector applique cette règle à tous les pods avec un certain libellé. : source: Cette règle s'applique aux demandes provenant de n'importe quelle source.

selector

Le sélecteur doit cibler le même trafic que l'accès original-nginx Kubernetes NetworkPolicy. Comme il s'agit d'une politique de type Calico, vous devez inclure projectcalico.org/orchestrator == 'k8s' pour indiquer qu'elle s'applique à tous les pods de l'espace de noms de la politique, en plus de l'original run == 'nginx'.

order

Les règles Calico ont un ordre qui détermine à quel moment elles sont appliquées aux paquets de demandes entrantes. Les règles avec les ordres les moins élevés, par exemple 1000, sont appliquées en premier. Les règles avec les ordres les plus élevés sont appliquées après les règles dont les ordres sont plus faibles. Par exemple, une politique de très haut niveau, telle que 3000, est effectivement appliquée en dernier, une fois que toutes les politiques de niveau inférieur ont été appliquées. Les paquets de demandes entrantes passent par la chaîne de règles Iptables et tentent d'abord de correspondre aux règles d'ordre moins élevé. Si un paquet correspond à une règle, le paquet est accepté. Toutefois, si un paquet ne correspond à aucune règle, il arrive à la dernière règle de la chaîne de règles Iptables avec l'ordre le plus élevé. Pour garantir qu'il s'agit de la dernière règle dans la chaîne, utilisez un ordre beaucoup plus élevé, par exemple 3000, par rapport à celui de la règle que vous avez créée à l'étape 1. Notez que les Kubernetes NetworkPolicy sont appliquées dans l'ordre indiqué 1000.

3. Appliquez la politique.

   kubectl apply -f log-denied-packets.yaml
   

4. Générez des entrées de journal en envoyant des demandes qui ne sont pas autorisées par la règle que vous avez créée à l'étape 1. Par exemple, essayez d'exécuter une commande PING sur le pod protégé par la stratégie de réseau à partir d'une adresse IP ou d'une adresse IP non autorisée.

5. Recherchez les entrées de journal qui sont écrites dans le chemin /var/log/syslog. Les adresses IP DST (destination) ou SRC (source) dans l'entrée de journal peuvent être différentes de celles prévues en raison des proxy, de la conversion d'adresses réseau et d'autres processus réseau. L'entrée de journal se présente comme suit :

   Sep 5 14:34:40 <worker_hostname> kernel: [158271.044316] calico-packet: IN=eth1 OUT= MAC=08:00:27:d5:4e:57:0a:00:27:00:00:00:08:00 SRC=192.XXX.XX.X DST=192.XXX.XX.XX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52866 DF PROTO=TCP SPT=42962 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
   

6. Facultatif : acheminez les journaux depuis /var/log/syslog vers IBM Cloud Logs ou vers un serveur syslog externe.