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é. Cette HostEndpointpermet aux utilisateurs de cluster de restreindre davantage le trafic réseau privé en créant des règles Calico qui sélectionnentibm.role: worker_private et dont le numéro de commande est inférieur à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 stratégies par défaut de votre cluster, car elles sont recréées lors de la prochaine actualisation ou 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 règles Kubernetes par défaut limitant l'accès au tableau de bord 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.

Installation et configuration de l'Interface de ligne de commande Calico

Pour afficher, gérer et ajouter des règles Calico, installez et configurez l'interface de ligne de commande de Calico.

1. Définissez le contexte de votre cluster pour exécuter des commandes Calico.

   • Kubernetes version 1.19 ou ultérieure :

     1. Téléchargez le fichier de configuration kubeconfig de votre cluster.

        ibmcloud ks cluster config --cluster <cluster_name_or_ID>
        

     2. Définissez la variable d'environnement DATASTORE_TYPE sur kubernetes.

        export DATASTORE_TYPE=kubernetes
        

2. Si les règles réseau d'entreprise utilisent des proxys ou des pare-feux pour empêcher l'accès depuis votre système local à des noeuds finaux publics, autorisez l'accès TCP pour les commandes Calico.

3. Suivez la procédure d'installation de l'outil de ligne de commande calicoctl .

   • Linux et OS X

     1. Téléchargez la version de l'interface de ligne de commande(Calico)correspondant à votre système d'exploitation. Pour OS X, vous devrez peut-être autoriser manuellement l'ouverture et l'exécution du fichier téléchargé en accédant à Préférences Système > Sécurité et confidentialité > Général.

     2. Déplacez le fichier vers le répertoire /usr/local/bin.

        mv <filepath>/<filename> /usr/local/bin/calicoctl
        

     3. Rendez le fichier exécutable.

        chmod +x /usr/local/bin/calicoctl
        

     4. Vérifiez qu'il n'existe pas d'ancien fichier de configuration Calico calicoctl.cfg dans le répertoire /etc/calico. Si le fichier /etc/calico/calicoctl.cfg existe, supprimez-le.

   • Windows

     1. Téléchargez l'interface de ligne de commande Calico. Lorsque vous sauvegardez le fichier, renommez-le calicoctl.exe et placez-le dans le même répertoire que l'interface de ligne de commande d'IBM Cloud. Cette configuration vous évite diverses modifications de chemin de fichier lorsque vous exécutez des commandes par la suite.

     2. Définissez la variable d'environnement sur le fichier de configuration de votre cluster.

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/kube-config.yaml
        

4. Vérifiez que la configuration Calico fonctionne correctement.

   calicoctl get nodes
   

   Exemple de sortie

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

La modification du plug-in, des composants ou des paramètres Calico par défaut n'est pas prise en charge. Par exemple, ne déployez pas de nouvelle version de plug-in Calico ou modifiez les ensembles de démons ou les déploiements pour les composants Calico, les ressources IPPool par défaut ou les nœuds Calico. A la place, vous pouvez suivre la documentation pour modifier la MTU Calico ou pour désactiver le plug-in de mappage de port pour l'interface CNI Calico si nécessaire.

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 Calico et définissez le contexte de votre cluster pour exécuter des commandes Calico.

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

   calicoctl get hostendpoint -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.

   Les politiques réseau sont définies pour des espaces de noms spécifiques :

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

   Les politiques de réseau global ne sont pas limitées à des espaces de noms spécifiques :

   calicoctl get GlobalNetworkPolicy -o wide
   

3. Affichez les informations détaillées d'une règle réseau.

   calicoctl get NetworkPolicy -o yaml <policy_name> --namespace <policy_namespace>
   

4. Affichez les informations détaillées de toutes les règles réseau globales pour le cluster.

   calicoctl get GlobalNetworkPolicy -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 stratégies réseau d' Kubernetes, consultez la documentation sur les stratégies réseau d' Kubernetes.

Pour créer des règles Calico, procédez comme indiqué ci-après. Avant de commencer, installez et configurez l'interface de ligne de commande Calico et définissez le contexte de votre cluster pour exécuter des commandes Calico.

1. Définissez votre stratégie réseau d' Calico s ou votre stratégie réseau globale en créant un script de configuration (.yaml) avec une syntaxe de stratégie d' 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.

   Pour les nouveaux clusters mis à disposition à la version 1.29 ou ultérieure, les noms abrégés pour globalnetworkpolicies.crd.projectcalico.org (gnp) et hostendpoints.crd.projectcalico.org (hep) ne sont pas pris en charge. Toutefois, si vous mettez à niveau un cluster vers la version 1.29 ou une version ultérieure, les noms abrégés sont toujours pris en charge.

2. Appliquez les règles au cluster. Si vous disposez d'un système Windows, incluez l'option --config=<filepath>/calicoctl.cfg.

   calicoctl apply -f policy.yaml [--config=<filepath>/calicoctl.cfg]
   

Notez que les règles de réseau Calico et Kubernetes bloquent uniquement les nouvelles connexions, mais qu'elles n'interrompent pas les connexions qui existaient avant l'application de la règle. Ainsi, après avoir appliqué une politique nouvelle ou modifiée, pour vérifier qu'elle fonctionne et ne bloque pas qu'elle ne le devrait, procédez comme suit :

1. Redémarrez les pods susceptibles d'être affectées par la règle. Mieux encore, redémarrez tous les pods, juste au cas où vous n'auriez pas le bon sélecteur et que cela affecte plus de personnes que vous ne le pensez.

2. Exécutez ibmcloud ks cluster master refresh -c CLUSTER-IDpour redémarrer vos pods maître de cluster. Cela va interrompre les connexions existantes du kubelet et d'autres composants vers le maître et les forcer à se reconnecter. Cela vous montrera si les nouvelles règles et les règles modifiées bloquent toutes les connexions nécessaires à vos composants maîtres.

3. Essayez de vous connecter au tableau de bord d' Kubernetes, afin de vous assurer que les modifications de la politique ne bloquent pas les connexions nécessaires à 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é

Nous fournissons un ensemble d'exemples de règles de réseau public Calico qui restreignent davantage le trafic réseau public / privé sur les noeuds worker de cluster. Ces politiques autorisent le trafic nécessaire au déploiement du cluster et bloquent certains autres types de trafic.

Ces politiques ne sont pas destinées à tout bloquer, et ne satisfassent pas nécessairement les exigences de conformité. Elles sont conçues comme un point de départ et doivent être modifiées pour répondre à vos cas d'utilisation particulières. Pour plus d'informations, voir le fichier README.

A chaque fois que de nouveaux emplacements pour IBM Cloud Kubernetes Service et d'autres IBM Cloud sont activés, les sous-réseaux pour ces emplacements sont ajoutés aux stratégies Calico. Veillez à surveiller le référentiel GitHub pour toute mise à jour de ces règles.

Notez que nous ne recommandons plus l'utilisation des exemples de règles allow-egress-pods-public, allow-public-services-pods, allow-egress-pods-private ou allow-private-services-pods dans les sections ci-dessous consacrées aux règles des réseaux publics et privés. Ces politiques contrôlent les sorties de tous les pods du cluster. Si vous souhaitez contrôler le trafic vers/depuis les pods, vous devez utiliser Kubernetes NetworkPolicy et cibler des espaces de noms et des pods spécifiques au lieu 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.

Avant de commencer, installez et configurez l'interface de ligne de commande Calico et définissez le contexte de votre cluster pour exécuter des commandes 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.

      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 d' Calico s suivante utilise le même sélecteur de pod que l'exemple de politique d' access-nginx Kubernetes décrit à 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 avec la baliserun=access seront immédiatement acceptées, ce qui signifie qu'aucune autre politique n'est évaluée.

   • Si la connexion provient d'un pod sans l'étiquette « run=access » (ou de tout ce qui n'est pas un pod), l' Kubernetes NetworkPolicy ne fera rien et Calico évalue 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 pour tout trafic entrant, et ne fait pas référence au trafic uniquement à partir de l'ALB entrant IBM. | ingress

   : action: L'action Log écrit une entrée de journal pour toutes les demandes qui correspondent à cette règle sur le chemin /var/log/syslog sur le nœud wrker

   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. Puisqu'il s'agit d'une politique d' 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' run == 'nginx' d'origine.

   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 police avec un ordre très élevé, telle que 3000, est effectivement appliquée en dernier après que toutes les polices d'ordre 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. Note that Kubernetes NetworkPolicy are applied as order- 1000.

3. Appliquez la politique. Si vous utilisez un ordinateur Windows, ajoutez l'option --config=<filepath>/calicoctl.cfg.

   calicoctl apply -f log-denied-packets.yaml [--config=<filepath>/calicoctl.cfg]
   

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.