Alibaba Cloud Service Mesh:Run an ASM authorization policy in trial mode

Prérequis

• Une instance ASM (version 1.14 ou ultérieure) avec au moins un cluster ajouté. Pour ajouter un cluster, consultez la rubrique Ajouter un cluster à une instance ASM. Pour mettre à jour votre instance ASM, consultez la rubrique Mettre à jour une instance ASM.

• Un namespace nommé foo avec l'injection automatique du proxy sidecar activée. Pour plus de détails, consultez la rubrique Gérer les namespaces globaux.

• kubectl connecté au cluster. Pour plus de détails, consultez la rubrique Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour se connecter au cluster.

Étape 1 : Déployer les applications de test et vérifier la connectivité

Déployez deux charges de travail exemples : sleep (un client basé sur curl) et HTTPBin (un serveur echo HTTP), puis confirmez qu'elles peuvent communiquer.

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

   sleep.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
     namespace: foo
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     namespace: foo
     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

2. Déployez l'application sleep dans le namespace foo :

   kubectl apply -f sleep.yaml -n foo

3. Créez un fichier httpbin.yaml avec le contenu suivant :

   httpbin.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: httpbin
     namespace: foo
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: httpbin
     namespace: foo
     labels:
       app: httpbin
       service: httpbin
   spec:
     ports:
     - name: http
       port: 8000
       targetPort: 80
     selector:
       app: httpbin
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin
     namespace: foo
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: httpbin
         version: v1
     template:
       metadata:
         labels:
           app: httpbin
           version: v1
       spec:
         serviceAccountName: httpbin
         containers:
         - image: docker.io/kennethreitz/httpbin
           imagePullPolicy: IfNotPresent
           name: httpbin
           ports:
           - containerPort: 80

4. Déployez l'application HTTPBin dans le namespace foo :

   kubectl apply -f httpbin.yaml -n foo

5. Envoyez 20 requêtes depuis le pod sleep vers HTTPBin pour vérifier la connectivité :

   for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s -o /dev/null -w "%{http_code}\n"; done

   Résultat attendu :

   200
   200
   200
   ...

   Les 20 requêtes renvoient toutes le code 200, ce qui confirme la connectivité entre les deux applications.

Étape 2 : Créer une politique d'autorisation avec le mode essai activé

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 votre instance ASM. Dans le volet de navigation de gauche, sélectionnez Mesh Security Center > AuthorizationPolicy. Cliquez sur Create.

3. Configurez la politique d'autorisation pour refuser des requêtes spécifiques, activez l'interrupteur du mode essai, puis cliquez sur Create.

   

Étape 3 : Vérifier les résultats du mode essai via les journaux

En mode essai, la politique évalue chaque requête sans appliquer ses décisions. Le proxy sidecar enregistre chaque résultat d'évaluation dans ses journaux.

1. Envoyez 20 requêtes depuis le pod sleep vers HTTPBin :

   for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s -o /dev/null -w "%{http_code}\n"; done

   Résultat attendu :

   200
   200
   200
   ...

   Toutes les requêtes renvoient toujours le code 200. La politique a évalué chaque requête, mais n'a pas appliqué le refus.

2. Définissez le niveau de journalisation RBAC du proxy sidecar HTTPBin sur debug afin que les résultats d'évaluation du mode essai apparaissent dans les journaux :

   kubectl exec "$(kubectl get pod -l app=httpbin -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- curl -X POST 127.0.0.1:15000/logging?rbac=debug

   Résultat attendu :

   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                    Dload  Upload   Total   Spent    Left  Speed
     0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0active loggers:
     ...
     rbac: debug
     ...
   100  1028    0  1028    0     0  1003k      0 --:--:-- --:--:-- --:--:-- 1003k

3. Filtrez les journaux du proxy sidecar pour identifier les entrées de refus en mode essai :

   kubectl logs "$(kubectl -n foo -l app=httpbin get pods -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo | grep "shadow denied"

   Exemple de résultat :

   2023-12-20T03:58:47.107915Z     debug   envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130        shadow denied, matched policy ns[foo]-policy[test]-rule[0]     thread=32
   2023-12-20T03:58:48.800098Z     debug   envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130        shadow denied, matched policy ns[foo]-policy[test]-rule[0]     thread=33
   2023-12-20T03:58:50.420179Z     debug   envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130        shadow denied, matched policy ns[foo]-policy[test]-rule[0]     thread=32

   Chaque entrée shadow denied indique que la politique aurait refusé la requête. La portion matched policy ns[foo]-policy[test]-rule[0] identifie la politique et la règle correspondantes.

Étape 4 : Appliquer la politique d'autorisation

Une fois que vous avez confirmé que les résultats du mode essai correspondent à vos attentes, désactivez le mode essai pour commencer à appliquer la politique.

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 votre instance ASM. Dans le volet de navigation de gauche, sélectionnez Mesh Security Center > AuthorizationPolicy.

3. Recherchez la politique d'autorisation créée à l'étape 2, désactivez l'interrupteur dans la colonne Commissioning mode, puis cliquez sur OK dans la boîte de dialogue Submit.

4. Envoyez 20 requêtes pour confirmer que la politique applique bien les refus :

   for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s -o /dev/null -w "%{http_code}\n"; done

   Résultat attendu :

   403
   403
   403
   ...

   Toutes les requêtes renvoient le code 403, ce qui confirme que la politique refuse désormais activement le trafic.

5. Réinitialisez le niveau de journalisation RBAC du proxy sidecar HTTPBin sur warning :

   kubectl exec "$(kubectl get pod -l app=httpbin -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- curl -X POST 127.0.0.1:15000/logging?rbac=warning

   Résultat attendu :

   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                    Dload  Upload   Total   Spent    Left  Speed
     0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:-- --:--:--     0active loggers:
     ...
     rbac: warning
     ...
   100  1028    0  1028    0     0  1003k      0 --:--:-- --:--:-- --:--:-- 1003k

Étapes suivantes

• Configurer des politiques d'autorisation pour le contrôle d'accès aux charges de travail — Restreignez l'accès par chemin de requête, méthode ou adresse IP client.

• Configurer des politiques d'autorisation pour les requêtes HTTP et Configurer des politiques d'autorisation pour les requêtes TCP — Contrôle d'accès granulaire entre services.

• Utiliser une politique d'autorisation pour contrôler le trafic d'accès depuis les services d'une instance ASM vers un site web externe et Utiliser une politique d'autorisation pour contrôler le trafic d'accès depuis les services d'une instance ASM vers une base de données externe — Contrôle d'accès sortant pour les services du maillage.

• Configurer les fonctionnalités de génération et de collecte des journaux d'accès d'une passerelle ASM — Personnalisez les journaux d'accès de la passerelle pour la surveillance de la sécurité.

• Utiliser la fonctionnalité d'audit des opérations KubeAPI dans ASM et Configurer des alertes d'audit pour les opérations sur les ressources ASM — Suivez et alertez sur les modifications des ressources ASM.