1.2. Service Mesh - Notes de mise à jour

L'espace de noms openshift-operators comprend un nouveau DaemonSet istio CNI istio-cni-node-v2-3 et une nouvelle ressource ConfigMap, istio-cni-config-v2-3.

Lors de la mise à niveau vers le Service Mesh Control Plane 2.3, le DaemonSet istio-cni-node existant n'est pas modifié et un nouveau DaemonSet istio-cni-node-v2-3 est créé.

Ce changement de nom n'affecte pas les versions précédentes ou tout istio-cni-node CNI DaemonSet associé à un plan de contrôle Service Mesh déployé à l'aide d'une version précédente.

Cette version introduit la prise en charge généralement disponible de l'injection de passerelle. Les configurations de passerelle sont appliquées aux proxys Envoy autonomes qui s'exécutent à la périphérie du maillage, plutôt qu'aux proxys Envoy sidecar qui s'exécutent aux côtés de vos charges de travail de service. Cela permet de personnaliser les options de passerelle. Lorsque vous utilisez l'injection de passerelle, vous devez créer les ressources suivantes dans l'espace de noms où vous souhaitez exécuter votre proxy de passerelle : Service, Deployment, Role, et RoleBinding.

Service Mesh 2.3 est basé sur Istio 1.14, qui apporte de nouvelles fonctionnalités et des améliorations au produit. Bien que de nombreuses fonctionnalités d'Istio 1.14 soient prises en charge, il convient de noter les exceptions suivantes :

Cette version introduit une version Technology Preview de la console OpenShift Container Platform Service Mesh, qui intègre l'interface Kiali directement dans la console web OpenShift. Pour plus d'informations, voir Introducing the OpenShift Service Mesh Console (A Technology Preview)

Cette version introduit le déploiement à l'échelle du cluster en tant que fonctionnalité de l'aperçu technologique. Un déploiement à l'échelle d'un cluster contient un plan de contrôle Service Mesh qui surveille les ressources pour un cluster entier. Le plan de contrôle utilise une seule requête dans tous les espaces de noms pour surveiller chaque type de ressource Istio ou Kubernetes qui affecte la configuration du maillage. En revanche, l'approche multitenant utilise une requête par espace de noms pour chaque type de ressource. La réduction du nombre de requêtes effectuées par le plan de contrôle dans le cadre d'un déploiement à l'échelle du cluster améliore les performances.

  apiVersion: maistra.io/v2
  kind: ServiceMeshControlPlane
  metadata:
    name: cluster-wide
    namespace: istio-system
  spec:
    version: v2.3
    techPreview:
      controlPlaneMode: ClusterScoped 1

  apiVersion: maistra.io/v1
  kind: ServiceMeshMemberRoll
  metadata:
    name: default
  spec:
    members:
    - '*' 1

Avec cette amélioration, en plus de copier les annotations, vous pouvez copier des étiquettes spécifiques pour une route OpenShift. Red Hat OpenShift Service Mesh copie toutes les étiquettes et annotations présentes dans la ressource Istio Gateway (à l'exception des annotations commençant par kubectl.kubernetes.io) dans la ressource OpenShift Route gérée.

Cette version ajoute la prise en charge de l'API WasmPlugin et supprime l'API ServiceMeshExtension.

Cette version introduit la prise en charge du maillage de services pour Red Hat OpenShift sur AWS (ROSA), y compris la fédération multi-cluster.

Dans cette version, le DaemonSet istio-node est renommé istio-cni-node pour correspondre au nom dans Istio en amont.

Istio 1.10 a mis à jour Envoy pour envoyer le trafic au conteneur d'application en utilisant eth0 au lieu de lo par défaut.

Cette version marque la fin de la prise en charge des plans de contrôle Service Mesh basés sur Service Mesh 1.1 pour toutes les plateformes.

Service Mesh 2.2 est basé sur Istio 1.12, qui apporte de nouvelles fonctionnalités et des améliorations au produit. Bien que de nombreuses fonctionnalités d'Istio 1.12 soient prises en charge, il convient de noter les fonctionnalités suivantes qui ne sont pas prises en charge :

Kubernetes Gateway API est une fonctionnalité d'aperçu technologique qui est désactivée par défaut. Si le contrôleur de déploiement de l'API Kubernetes est désactivé, vous devez déployer et lier manuellement une passerelle d'entrée à l'objet Gateway créé.

Si le contrôleur de déploiement de l'API Kubernetes est activé, une passerelle d'entrée est automatiquement déployée lorsqu'un objet Gateway est créé.

$ kubectl get crd gateways.gateway.networking.k8s.io || { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.0" | kubectl apply -f -; }

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: "true"
            PILOT_ENABLE_GATEWAY_API_STATUS: "true"
            # and optionally, for the deployment controller
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"

  apiVersion: gateway.networking.k8s.io/v1alpha2
  kind: Gateway
  metadata:
    name: gateway
  spec:
    addresses:
    - value: ingress.istio-gateways.svc.cluster.local
      type: Hostname

Red Hat OpenShift Service Mesh crée et gère automatiquement un certain nombre de ressources NetworkPolicies dans le plan de contrôle Service Mesh et les espaces de noms des applications. Cela permet de s'assurer que les applications et le plan de contrôle peuvent communiquer entre eux.

Si vous souhaitez désactiver la création et la gestion automatiques des ressources NetworkPolicies, par exemple pour appliquer les politiques de sécurité de votre entreprise, vous pouvez le faire. Vous pouvez modifier le site ServiceMeshControlPlane pour définir le paramètre spec.security.manageNetworkPolicy sur false

De nouvelles définitions de ressources personnalisées (CRD) ont été ajoutées pour prendre en charge la fédération des maillages de services. Les maillages de services peuvent être fédérés à la fois au sein d'un même cluster ou entre différents clusters OpenShift. Ces nouvelles ressources incluent :

Service Mesh Federation n'est pas pris en charge entre les clusters sur Red Hat OpenShift Service on AWS (ROSA), Azure Red Hat OpenShift (ARO), ou OpenShift Dedicated (OSD).

L'interface OVN-Kubernetes Container Network Interface (CNI) a été précédemment introduite en tant que fonctionnalité d'aperçu technologique dans Red Hat OpenShift Service Mesh 2.0.1 et est maintenant généralement disponible dans Red Hat OpenShift Service Mesh 2.1 et 2.0.x pour une utilisation sur OpenShift Container Platform 4.7.32, OpenShift Container Platform 4.8.12, et OpenShift Container Platform 4.9.

Le site ServiceMeshExtensions Custom Resource Definition (CRD), introduit pour la première fois dans la version 2.0 en tant qu'aperçu technologique, est désormais disponible de manière générale. Vous pouvez utiliser la CRD pour créer vos propres plugins, mais Red Hat ne fournit pas de support pour les plugins que vous créez.

Mixer a été complètement supprimé dans Service Mesh 2.1. La mise à jour d'une version 2.0.x de Service Mesh vers la version 2.1 sera bloquée si Mixer est activé. Les plugins Mixer devront être portés vers WebAssembly Extensions.

Avec le retrait officiel de Mixer, OpenShift Service Mesh 2.1 ne supporte pas l'adaptateur de mélangeur 3scale. Avant de passer à Service Mesh 2.1, supprimez l'adaptateur 3scale basé sur Mixer et tous les plugins Mixer supplémentaires. Ensuite, installez et configurez manuellement le nouvel adaptateur 3scale WebAssembly avec Service Mesh 2.1 en utilisant une ressource ServiceMeshExtension.

3scale 2.11 introduit une nouvelle intégration de Service Mesh basée sur WebAssembly.

Service Mesh 2.1 est basé sur Istio 1.9, qui apporte un grand nombre de nouvelles fonctionnalités et d'améliorations du produit. Bien que la majorité des fonctionnalités d'Istio 1.9 soient prises en charge, il convient de noter les exceptions suivantes :

Le temps que Red Hat OpenShift Service Mesh utilise pour élaguer les anciennes ressources à la fin de chaque rapprochement ServiceMeshControlPlane a été réduit. Cela se traduit par des déploiements ServiceMeshControlPlane plus rapides, et permet aux changements appliqués aux SMCP existants de prendre effet plus rapidement.

Kiali 1.36 comprend les fonctionnalités et améliorations suivantes :

Red Hat OpenShift Service Mesh contient une vulnérabilité exploitable à distance, CVE-2021-39156, où une requête HTTP avec un fragment (une section à la fin d'un URI qui commence par un caractère #) dans le chemin URI pourrait contourner les politiques d'autorisation basées sur le chemin URI d'Istio. Par exemple, une politique d'autorisation d'Istio refuse les requêtes envoyées au chemin URI /user/profile. Dans les versions vulnérables, une requête avec le chemin URI /user/profile#section1 contourne la politique de refus et se dirige vers le backend (avec l'URI normalisé path /user/profile#section1), ce qui peut conduire à un incident de sécurité.

Vous êtes concerné par cette vulnérabilité si vous utilisez des politiques d'autorisation avec des actions DENY et operation.paths, ou des actions ALLOW et operation.notPaths.

Avec l'atténuation, la partie fragmentaire de l'URI de la demande est supprimée avant l'autorisation et l'acheminement. Cela empêche une demande contenant un fragment dans son URI de contourner les politiques d'autorisation qui sont basées sur l'URI sans la partie fragment.

Pour ne pas être concerné par le nouveau comportement dans l'atténuation, la section du fragment dans l'URI sera conservée. Vous pouvez configurer votre site ServiceMeshControlPlane pour qu'il conserve les fragments de l'URI.

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  techPreview:
    meshConfig:
      defaultConfig:
        proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"

Istio génère des noms d'hôtes à la fois pour le nom d'hôte lui-même et pour tous les ports correspondants. Par exemple, un service virtuel ou une passerelle pour un hôte de "httpbin.foo" génère une configuration correspondant à "httpbin.foo et httpbin.foo:*". Cependant, les politiques d'autorisation de correspondance exacte ne correspondent qu'à la chaîne exacte donnée pour les champs hosts ou notHosts.

Votre cluster est affecté si vous avez des ressources AuthorizationPolicy utilisant la comparaison de chaînes exactes pour la règle de détermination des hosts ou notHosts.

Vous devez mettre à jour les règles de votre politique d'autorisation pour utiliser la correspondance des préfixes au lieu de la correspondance exacte. Par exemple, en remplaçant hosts: ["httpbin.com"] par hosts: ["httpbin.com:*"] dans le premier exemple AuthorizationPolicy.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        hosts: [“httpbin.com”,"httpbin.com:*"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: default
spec:
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["httpbin.example.com:*"]

Istio contient une vulnérabilité exploitable à distance où un chemin de requête HTTP avec plusieurs barres obliques ou des caractères obliques échappés (/ ou \) pourrait potentiellement contourner une politique d'autorisation Istio lorsque des règles d'autorisation basées sur le chemin sont utilisées.

Par exemple, supposons qu'un administrateur de cluster Istio définisse une politique d'autorisation DENY pour rejeter la demande au chemin /admin. Une demande envoyée au chemin URL //admin ne sera PAS rejetée par la politique d'autorisation.

Selon la RFC 3986, le chemin //admin avec plusieurs barres obliques devrait techniquement être traité comme un chemin différent du chemin /admin. Cependant, certains services backend choisissent de normaliser les chemins URL en fusionnant les barres obliques multiples en une seule barre oblique. Cela peut entraîner un contournement de la politique d'autorisation (//admin ne correspond pas à /admin), et un utilisateur peut accéder à la ressource au chemin /admin dans le backend ; cela représenterait un incident de sécurité.

Votre cluster est concerné par cette vulnérabilité si vous avez des politiques d'autorisation qui utilisent les modèles ALLOW action notPaths field ou DENY action paths field. Ces modèles sont vulnérables à des contournements inattendus de la politique.

Votre cluster n'est PAS affecté par cette vulnérabilité si :

Les politiques d'autorisation d'Istio peuvent être basées sur les chemins d'URL dans la requête HTTP. La normalisation des chemins, également connue sous le nom de normalisation des URI, modifie et normalise les chemins des requêtes entrantes afin que les chemins normalisés puissent être traités de manière standard. Des chemins syntaxiquement différents peuvent être équivalents après la normalisation du chemin.

Istio prend en charge les schémas de normalisation suivants sur les chemins de requête avant de les évaluer par rapport aux politiques d'autorisation et d'acheminer les requêtes :

Les algorithmes de normalisation sont exécutés dans l'ordre suivant :

S'assurer qu'Envoy normalise les chemins d'accès aux requêtes pour qu'ils correspondent aux attentes de vos services d'arrière-plan est essentiel pour la sécurité de votre système. Les exemples suivants peuvent vous servir de référence pour configurer votre système. Les chemins d'URL normalisés, ou les chemins d'URL originaux si NONE est sélectionné, seront les suivants :

Pour configurer la normalisation des chemins pour Red Hat OpenShift Service Mesh, spécifiez ce qui suit dans votre ServiceMeshControlPlane. Utilisez les exemples de configuration pour vous aider à déterminer les paramètres de votre système.

spec:
  techPreview:
    global:
      pathNormalization: <option>

Dans certains environnements, il peut être utile de comparer les chemins d'accès dans les politiques d'autorisation sans tenir compte de la casse. Par exemple, traiter https://myurl/get et https://myurl/GeT comme équivalents. Dans ce cas, vous pouvez utiliser le filtre EnvoyFilter présenté ci-dessous. Ce filtre modifie à la fois le chemin utilisé pour la comparaison et le chemin présenté à l'application. Dans cet exemple, istio-system est le nom du projet de plan de contrôle Service Mesh.

Enregistrez le site EnvoyFilter dans un fichier et exécutez la commande suivante :

oc create -f <myEnvoyFilterFile>

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end