Istio & Service Mesh – Contrôlez et tunez les flux entre vos micro services

Istio Security – Sécurisation des échanges de votre service mesh

Istio fourni de base une couche de sécurité à votre service mesh. Les services de votre mesh communiquent de manière chiffrée grâce à un Mutual TLS dont les certificats sont soit gérés en interne par Istio soit fournis par vous même. Ils sont aussi capables de communiquer en clair pour être accessibles par des services hors de votre service mesh mais cette politique de chiffrement peut être activé de manière exclusive afin de protéger les échanges d’attaques Man in the Middle. Istio permet d’associer à un service/namespace des politiques d’accès afin de contrôler qui peut consommer quoi. Enfin le tout est auditable via des extensions au niveau des proxy envoy présent dans les pods de chacun de vos micro services.

Kubernetes met à disposition des objets Network Policy permettant par exemple de rendre étanche des namespaces. Cette fonctionnalité est également disponible avec Istio mais comme pour les sections déjà vu de cet article, Istio propose d’aller plus loin.

Authentication Policies

Il existe deux types de politiques d’authentification

• De service à service
• Un utilisateur à un service

Le premier point est assuré naturellement par Istio via le chiffrement Mutual TLS. Aucune modification de code applicatif n’est nécéssaire. Dans les coulisses un système de certificat est mis en oeuvre avec rotation automatique.

Le second point est un cas classique des applications web puisque Istio peut contrôler qu’un Jeton JWT est présent dans les requêtes avant d’autoriser l’accès à un endpoint. La validation de jeton JWT est compatible avec un fournisseur personnalisé de jeton ou encore n’importe quel fournisseur compatible OpenID.

Authorization Policies

Les politiques d’autorisation agissent sur les deux mêmes points que les politiques d’authentification. Elles vont permettre de contrôler qui peut accéder à quoi en fonction de plusieurs éléments comme la provenance, les éléments présents dans la requête etc.

Un cas qui va se produire lors d’une migration d’un monolithe vers un ensemble de micro service est le remplacement des points d’injection JAVA. L’appel HTTP est une alternative et dans ce cas va nécessite l’exposition de nouveaux endpoints sur le micro service. Ces endpoints servent pour du traitement interne ne doivent pas être exposés aux autres applications consommatrices.

Une politique d’autorisation possède les elements suivants :

• Qui concerne elle ?
  • Namespace, pods
• Quelle est l’action de la politique ?
  • ALLOW/DENY
• Sur un flux en provenance de [Facultatif]
  • D’un principal, namespace, ip
• En direction de [Facultatif]
  • Nom d’hote, port, verbe HTTP, path de la méthode
• Quand [Facultatif]
  • Element de la requete = valeur

Il est à noter que pour plusieurs éléments de cette politique d’accès, l’opérateur « not » est disponible à partir de Istio v1.5. Ainsi il est possible de paramétrer une liste noire comme une liste blanche d’accès.

Point important : Dès l’application d’une première AuthorizationPolicy, vous devrez

• Configurer votre micro service pour communiquer en mTLS exclusivement. En effet, certains attributs ne seront propagés qu’en cas de communication chiffrée.
• Autoriser explicitement ce qui doit l’être car le comportement par defaut sera DENY ALL sauf ce qui est configuré

Application sur Workload 1

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: workload1-destination-rule
  namespace: workshop
spec:
  host: workload1-service
  subsets:
  - labels:
      version: v1
    name: v1
  - labels:
      version: v1b
    name: v1b
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        http2MaxRequests: 1
        maxRequestsPerConnection: 1
        maxRetries: 1024
      tcp:
        maxConnections: 1024
    loadBalancer:
      simple: LEAST_CONN
    outlierDetection:
      baseEjectionTime: 30s
      consecutiveErrors: 5
      interval: 10s
      maxEjectionPercent: 10
    tls:
      mode: ISTIO_MUTUAL #mTLS exclusivement

Nous allons prendre l’exemple de workload1 qui expose /hello mais aussi /private. Sans politique particulière, l’accès à /private est autorisé. Le test est réalisé avec Istio v1.4 qui ne possède pas l’opérateur not ni l’action DENY.

Nous allons paramétrer un accès autorisé uniquement pour la méthode /hello. L’appel depuis l’extérieur passant par l’objet Gateway d’istio, présent dans le namespace « istio-system » il s’agit de la manière de détecter un appel depuis l’extérieur du service mesh. Avec Istio v1.5 il est donc possible d’indiquer en source tout namespace qui n’est pas le namespace de déploiement du pod.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-hello-from-ext
  namespace: workshop
spec:
  rules:
  - from:
    - source:
        namespaces: ["istio-system"]
    to:
      - operation:
          paths: ["/hello","/favicon.ico"]

Après application, l’accès à la méthode /private est interdit.

Pour continuer à autoriser l’accès à /private à l’intérieur du namespace, il nous faut rajouter une politique supplémentaire

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-internal
  namespace: workshop
spec:
  rules:
  - from:
    - source:
        namespaces: ["workshop"]

Ainsi la méthode private est accessible en interne mais pas à l’exterieur.