Implement Zero Trust with ASM - Alibaba Cloud Service Mesh - Centre de documentation Alibaba Cloud

Le modèle de sécurité zéro confiance élimine toute confiance implicite, à l'intérieur comme à l'extérieur du périmètre réseau. Alibaba Cloud Service Mesh (ASM) constitue un cadre essentiel pour mettre en œuvre une architecture cloud native fondée sur le principe de zéro confiance. Il intègre les mécanismes d'authentification et d'autorisation directement au maillage de services, les extrayant ainsi du code applicatif. Cette approche offre une solution prête à l'emploi, dynamiquement configurable, permettant de mettre à jour les politiques de sécurité facilement et avec un effet immédiat. Cette rubrique explique pourquoi et comment utiliser ASM pour implémenter un système de sécurité zéro confiance.

Contexte

Les microservices offrent de nombreux avantages, notamment l'évolutivité, l'agilité, la mise à l'échelle indépendante, l'isolation de la logique métier, la gestion autonome du cycle de vie et la simplification du développement distribué. Toutefois, cette architecture distribuée introduit également des défis en matière de sécurité, car chaque microservice devient une cible potentielle pour les attaques. Kubernetes offre une excellente plateforme pour héberger et orchestrer ces microservices. Par défaut, cependant, toutes les communications entre les microservices ne sont pas sécurisées. Elles s'effectuent via HTTP en texte clair, ce qui ne satisfait pas aux exigences de sécurité modernes. S'appuyer uniquement sur un périmètre réseau pour assurer la sécurité est insuffisant. Si un service interne est compromis, un attaquant peut se déplacer latéralement pour cibler d'autres services au sein du réseau. Par conséquent, le trafic interne doit également être sécurisé. C'est ici que réside la valeur de la sécurité zéro confiance. Un modèle de zéro confiance exige une vérification explicite pour chaque requête et applique le principe du moindre privilège afin de restreindre l'accès aux ressources.

L'un des principaux avantages de la technologie Service Mesh réside dans sa capacité à sécuriser les environnements de production sans réduire la productivité des développeurs. Le Service Mesh pose les bases nécessaires à l'adoption d'une approche de sécurité zéro confiance pour les microservices. Cette démarche vous aide à atteindre des objectifs de sécurité tels qu'une authentification robuste des identités, une autorisation contextuelle et une journalisation ainsi qu'une supervision complètes de tous les accès. En exploitant ces fonctionnalités du maillage, vous pouvez appliquer des contrôles de sécurité à toutes les applications intégrées au maillage. Par exemple, vous pouvez garantir que tout le trafic est chiffré et que chaque flux entrant vers les applications est vérifié par un point d'application de politique (PEP).

Outre les politiques réseau Kubernetes pour la sécurité de niveau 3, ASM propose l'authentification mutuelle, l'authentification des requêtes, les politiques d'autorisation Istio et des politiques OPA granulaires. Ces capacités de sécurité zéro confiance intégrées à ASM vous aident à concrétiser vos objectifs de sécurité.

Le cadre théorique sous-jacent aux fonctionnalités d'ASM englobe les aspects suivants :

Identité de charge de travail : Fondement de la sécurité zéro confiance, ASM attribue une identité unifiée à chaque composant cloud native du Service Mesh. Il offre une méthode simple pour définir les identités de chaque charge de travail dans le maillage de services et fournit des mécanismes de personnalisation permettant d'étendre le système d'identité à des scénarios spécifiques. Ces identités sont compatibles avec la norme communautaire SPIFFE.
Certificats de sécurité : Les certificats constituent un élément central de la sécurité zéro confiance. ASM gère l'émission, le cycle de vie et la rotation des certificats. Chaque proxy utilise un certificat TLS X.509 pour établir son identité. ASM assure également la rotation des certificats et des clés privées.
Application des politiques : Un moteur de confiance basé sur des politiques se trouve au cœur du modèle zéro confiance. Outre la prise en charge des politiques de contrôle d'accès basé sur les rôles (RBAC) d'Istio, ASM fournit des politiques d'autorisation plus granulaires reposant sur OPA.
Visualisation et analyse : Pour offrir une visibilité sur le système de sécurité zéro confiance, ASM propose des mécanismes d'observabilité permettant de superviser les journaux et les métriques issus de l'exécution des politiques, ce qui vous permet d'évaluer les performances de chaque politique.

Pourquoi utiliser ASM pour implémenter la sécurité zéro confiance

L'architecture d'ASM offre plusieurs avantages en matière de sécurité par rapport à l'approche traditionnelle consistant à intégrer les mécanismes de sécurité directement dans le code applicatif :

Le cycle de vie du proxy sidecar est indépendant de l'application, ce qui facilite la gestion des proxys.
ASM permet une configuration dynamique. Vous pouvez mettre à jour les politiques facilement et les modifications prennent effet immédiatement, sans nécessiter de redéploiement de vos applications.
L'architecture de contrôle centralisée d'ASM permet aux équipes de sécurité de l'entreprise de concevoir, gérer et déployer des politiques de sécurité à l'échelle de toute l'organisation. Cela garantit que les applications métier sont sécurisées par défaut, et les développeurs bénéficient de ces politiques de sécurité sans effort supplémentaire.
ASM peut authentifier les informations d'identification de l'utilisateur final jointes à une requête, telles qu'un jeton Web JSON (JWT).
Avec l'architecture ASM, vous pouvez déployer les systèmes d'authentification et d'autorisation sous forme de services au sein du maillage. À l'instar des autres services du maillage, ces systèmes de sécurité bénéficient également des garanties de sécurité fournies par le maillage, y compris le chiffrement du transport, des identités robustes, des points d'application de politique ainsi que l'authentification et l'autorisation des informations d'identification des utilisateurs finaux.

Avec ASM, vous pouvez utiliser un seul plan de contrôle pour mettre en œuvre une gestion robuste des identités et des accès, un chiffrement TLS transparent, l'authentification, l'autorisation et la journalisation d'audit. Sa simplicité d'installation et de gestion permet aux développeurs, aux administrateurs système et aux équipes de sécurité de protéger leurs applications microservices.

Utilisation du système de sécurité zéro confiance d'ASM

ASM réduit la surface d'attaque dans les environnements cloud native et fournit le cadre fondamental d'un réseau applicatif basé sur le principe de zéro confiance. En gérant la sécurité entre les services, ASM garantit un chiffrement de bout en bout, une authentification au niveau des services et des politiques d'autorisation granulaires.

Le cadre ASM prend en charge les éléments suivants :

Application de l'authentification mutuelle TLS (mTLS) ou de l'authentification TLS côté serveur entre les services, avec prise en charge de la gestion automatique du cycle de vie des certificats, y compris leur rotation. Toutes les communications au sein du maillage sont authentifiées et chiffrées.
Activation d'une autorisation granulaire basée sur l'identité, ainsi que d'une autorisation fondée sur d'autres paramètres. S'appuyant sur le contrôle d'accès basé sur les rôles (RBAC), ASM adopte une posture de « moindre privilège », où seuls les services autorisés peuvent communiquer entre eux selon des règles ALLOW (autoriser) ou DENY (refuser).

ASM fournit des capacités fondamentales de sécurité zéro confiance, notamment l'identité de charge de travail, l'authentification mutuelle, l'authentification des requêtes, les politiques d'autorisation et les politiques OPA.

Identité de charge de travail

Lorsqu'une application s'exécute dans un environnement ASM, celui-ci attribue une identité unique à chaque service. Cette identité de service peut être utilisée pour l'authentification mutuelle afin de vérifier les accès entre les services et dans les politiques d'autorisation.

Lorsque vous utilisez ASM pour gérer les charges de travail exécutées sur Kubernetes, ASM fournit une identité de service pour chaque charge de travail. Cette identité repose sur le jeton de compte de service de la charge de travail.

Les identités de service dans ASM sont conformes à la norme SPIFFE et utilisent le format suivant : spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.

Connectez-vous à la console ASM pour consulter les services connectés depuis un cluster Kubernetes.

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez Mesh Security Center > Workload Identity.
Sur la page Workload Identity, définissez Data Plane sur l'ID du cluster et sélectionnez un Namespaces pour afficher les identités de charge de travail des services du cluster Kubernetes ajoutés au maillage de services.

Authentification mutuelle

ASM propose deux types d'authentification : l'authentification mutuelle et l'authentification des requêtes. L'authentification mutuelle utilise le protocole TLS mutuel pour authentifier les pairs lorsque deux microservices interagissent.

Si le client et le serveur disposent tous deux d'un proxy sidecar injecté, la communication mTLS est activée par défaut dans ASM.
Si seul le client dispose d'un proxy sidecar injecté, celui-ci décide d'utiliser ou non la communication mTLS en fonction de la configuration du serveur.
Si seul le serveur dispose d'un proxy sidecar injecté, le mode mTLS par défaut est PERMISSIVE, ce qui accepte à la fois le trafic en texte clair et le trafic chiffré. Si vous configurez une politique PeerAuthentication pour le serveur et définissez le mode mTLS sur STRICT, les requêtes échoueront.

Authentification des requêtes

L'authentification des requêtes permet aux utilisateurs finaux et aux systèmes d'interagir avec les microservices. Cela s'effectue généralement à l'aide d'un jeton Web JSON (JWT).

Lorsqu'un microservice est sollicité, vous pouvez créer une politique d'authentification des requêtes pour effectuer la validation JWT des requêtes entrantes. La politique valide les requêtes contenant un JWT. Seules les requêtes dotées d'un JWT valide peuvent accéder au service avec succès. Les requêtes sans JWT ne sont pas validées et peuvent accéder au service sans restriction.

Remarque

Pour garantir que seules les requêtes munies d'un JWT valide puissent accéder à un service, combinez l'authentification des requêtes avec une politique d'autorisation. Cette configuration refuse les requêtes comportant un JWT invalide ou aucun JWT.

Déployez l'application bookinfo qui recevra les requêtes. Pour plus d'informations, consultez la rubrique Déployer une application dans un cluster associé à une instance ASM.

Déployez l'application sleep qui enverra les requêtes.

Dans l'environnement KubeConfig de votre cluster ACK, créez un fichier sleep.yaml.

Fichier Sleep.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Exécutez la commande suivante pour déployer l'application sleep.
```
kubectl apply -f sleep.yaml -n default 
```

Créez une politique d'authentification des requêtes pour appliquer l'authentification JWT aux requêtes entrantes vers le service details.
1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.
2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez Mesh Security Center > RequestAuthentication. Sur la page qui s'affiche, cliquez sur Create.
3. Sur la page de création, configurez les paramètres suivants, puis cliquez sur Create pour définir une règle JWT pour la charge de travail details.
  
  Sélectionnez l'espace de noms default, définissez le nom sur test et ajoutez un sélecteur d'étiquette avec le nom app et la valeur details.
  
  Voici la description de certains paramètres :
  - issuer : l'émetteur du JWT. Pour cet exemple, définissez-le sur testing@secure.istio.io.
  - audiences : liste des audiences pour le JWT. Cela spécifie quels services peuvent utiliser le JWT pour accéder au service cible. Pour cet exemple, laissez ce champ vide, ce qui signifie que l'accès n'est pas restreint à un service spécifique.
  - jwks : le jeu de clés Web JSON (JWKS) pour le JWT. Pour cet exemple, utilisez le JWKS suivant. Pour plus d'informations, consultez jwks.json.
```
{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}
```

Pour générer le jeton utilisé à l'étape suivante, vous pouvez utiliser un outil JWT. Le jeton doit être créé à l'aide d'une clé privée correspondant à la clé publique du JWKS et inclure l'émetteur testing@secure.istio.io.

{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

Le jeton attendu est le suivant :

eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

Vérifiez que la politique d'authentification des requêtes est effective.

Exécutez la commande suivante pour accéder au service details en utilisant le JWT encodé.

export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'

Un code d'état 200 est renvoyé, indiquant un accès réussi.

Exécutez la commande suivante pour accéder au service details en utilisant un JWT invalide.

kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'

Un code d'état 403 est renvoyé, indiquant un échec d'accès.

Exécutez la commande suivante pour accéder au service details sans JWT.
```
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
```
Un code d'état 200 est renvoyé, indiquant un accès réussi.

Ces résultats montrent que les requêtes avec un JWT valide aboutissent, que les requêtes avec un JWT invalide échouent et que les requêtes sans JWT aboutissent. Cela confirme que la politique d'authentification des requêtes fonctionne comme prévu.

Politique d'autorisation

Lorsqu'un microservice est sollicité, vous pouvez utiliser une politique d'autorisation pour restreindre l'accès en fonction du port de la requête, de l'adresse IP, de la source, etc. Seules les requêtes répondant aux exigences peuvent accéder au service. La politique d'autorisation suivante restreint l'accès en fonction de la source de la requête en exigeant que celle-ci contienne un JWT émis par un émetteur spécifique.

Déployez l'application bookinfo qui recevra les requêtes. Pour plus d'informations, consultez la rubrique Déployer une application dans un cluster associé à une instance ASM.

Déployez l'application sleep qui enverra les requêtes.

Créez un fichier sleep.yaml avec le contenu suivant.

Fichier Sleep.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Dans l'environnement KubeConfig de votre cluster ACK, exécutez la commande suivante pour déployer l'application sleep.
```
kubectl apply -f sleep.yaml -n default 
```

Créez une politique d'autorisation.
1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.
2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez Mesh Security Center > AuthorizationPolicy. Sur la page qui s'affiche, cliquez sur Create from YAML.

Sur la page Create, sélectionnez l'espace de noms default, saisissez le code YAML suivant, puis cliquez sur Create.

Pour plus d'informations sur les champs, consultez la rubrique Authorization Policy.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals:
              - testing@secure.istio.io/testing@secure.istio.io
  selector:
    matchLabels:
      app: details

Exécutez la commande suivante pour envoyer une requête sans JWT afin d'accéder au service.
```
 kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
```
Résultat attendu :
```
403
```
La requête adressée au service details sans JWT échoue, ce qui confirme que la politique d'autorisation est effective. La politique exige que toutes les requêtes contiennent un JWT émis par testing@secure.istio.io pour accéder au service avec succès.

Politique OPA

OPA est un moteur de politiques qui permet un contrôle d'accès granulaire pour vos applications. En tant que moteur de politiques polyvalent, OPA peut être déployé en tant que service autonome aux côtés de vos microservices. Pour protéger une application, chaque requête adressée à un microservice doit être autorisée avant d'être traitée. Le microservice interroge l'API OPA pour déterminer si la requête doit être autorisée. Pour plus d'informations, consultez OPA.

ASM intègre un plug-in OPA, ce qui vous permet de définir des politiques de contrôle d'accès à l'aide d'OPA afin d'obtenir un contrôle d'accès granulaire pour vos applications. Ces politiques OPA peuvent également être mises à jour dynamiquement. Pour plus d'informations, consultez la rubrique Mettre à jour dynamiquement les politiques OPA dans ASM.

Résumé et cas d'utilisation

En résumé, ASM fournit les composants suivants qui renforcent la sécurité :

Une infrastructure de certificats gérée avec une gestion complète du cycle de vie des certificats, simplifiant l'émission des certificats et la rotation des autorités de certification.
Des API de plan de contrôle gérées pour distribuer les politiques d'authentification, les politiques d'autorisation et les informations de dénomination sécurisée aux proxys Envoy.
Des proxys sidecar qui agissent en tant que point d'application de politique (PEP) pour aider à sécuriser le maillage.
Des extensions de proxy Envoy qui permettent la collecte de télémétrie et l'audit.

Chaque charge de travail utilise un certificat TLS X.509 pour établir son identité. Ce certificat est ensuite utilisé par le proxy sidecar de la charge de travail. ASM fournit et fait tourner périodiquement ces certificats et clés privées. Si une clé privée est compromise, ASM peut la remplacer rapidement par une nouvelle, réduisant considérablement la surface d'attaque.

Cas d'utilisation

Utilisez une politique d'autorisation sur une passerelle d'entrée pour mettre en œuvre un contrôle d'accès basé sur l'adresse IP ou un contrôle d'accès basé sur un authorizer externe personnalisé.
Un client du secteur de la finance en ligne devait gérer les permissions d'accès pour des applications multilingues réparties sur plusieurs clusters. Il a utilisé les politiques d'autorisation ASM pour isoler les zones exposées à l'extérieur des zones d'application internes. En combinaison avec une passerelle de sortie pour auditer le trafic du maillage, il a également utilisé des politiques d'autorisation pour contrôler l'accès des applications aux services tiers.