Mettre à jour dynamiquement les politiques OPA dans ASM - - Centre de documentation Alibaba Cloud

Alibaba Cloud Service Mesh (ASM) s'intègre au plug-in Open Policy Agent (OPA), ce qui vous permet de définir des politiques de contrôle d'accès granulaires pour vos applications. Les instances ASM de version 1.8.6.41 ou ultérieure permettent de configurer un ConfigMap pour pousser automatiquement les politiques OPA vers les pods, activant ainsi la mise à jour dynamique des politiques. Cette rubrique explique comment mettre à jour dynamiquement les politiques OPA dans ASM.

Prérequis

Une instance ASM de version 1.8.6.41-gb1d8f288-aliyun ou ultérieure est créée. Pour plus d'informations, consultez la section Créer une instance ASM.
Un cluster managé ACK est créé. Pour plus d'informations, consultez la section Créer un cluster managé ACK.
Le cluster est ajouté à l'instance ASM.

Informations générales

Hébergé par la CNCF en tant que projet en incubation, Open Policy Agent (OPA) est un moteur de politiques permettant d'implémenter un contrôle d'accès granulaire pour vos applications. Moteur polyvalent, OPA se déploie comme 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. Le microservice interroge l'API OPA pour déterminer si la requête est permise. OPA

Étape 1 : Activer OPA

Connectez-vous à la console ASM.
Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, repérez l'instance ASM à configurer. Cliquez sur son nom ou sur Manage dans la colonne Actions.
Sur la page Basic Information, cliquez sur Settings en haut à droite.
Dans le panneau Settings Update, cochez Enable OPA plug-in.
Cliquez sur OK.

Sur la page Basic Information, le statut du plug-in OPA Plug-in passe à Enable.

Étape 2 : Créer des ConfigMaps

ASM prend en charge la mise à jour dynamique des politiques OPA. Configurez un Service Mesh avec le libellé openpolicyagent.org/policy=rego. La politique est alors automatiquement poussée vers tous les pods dotés d'un sidecar OPA injecté, dans tous les namespaces. La suppression du ConfigMap entraîne également la suppression de la politique des pods.

Important

Lorsque vous définissez une politique OPA pour un pod, n'incluez qu'un seul champ default allow. Si plusieurs ConfigMaps liés aux politiques OPA s'appliquent à un pod et que chaque politique définit un champ default allow, la présence de multiples champs default allow provoque l'échec des mises à jour dynamiques.
Le sidecar OPA dépend d'un ConfigMap nommé opa-policy pour démarrer. Si vous supprimez ce ConfigMap, la politique OPA correspondante est également supprimée du sidecar OPA. La recréation du ConfigMap ne restaure pas la politique. Vous devez recréer le pod.

Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour se connecter au cluster.
Créez un ConfigMap nommé opa-policy.

Le sidecar OPA nécessite un ConfigMap nommé opa-policy pour démarrer. Ce ConfigMap prend en charge les mises à jour dynamiques. Utilisez-le uniquement pour la configuration de base des politiques. Ajoutez des politiques complexes dynamiquement via d'autres ConfigMaps.
1. Créez un fichier YAML nommé opa-policy avec le contenu suivant :
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: | ### The paths allowed in this policy are required for dynamic OPA policy updates. If these paths are not configured, the updates will fail.
    package istio.authz
    import input.parsed_path
    allow {
            parsed_path[0] = "v1"
            parsed_path[1] = "policies"
    }
```
2. Exécutez la commande suivante pour créer le ConfigMap :
```
kubectl apply -f opa-policy.yaml
```

Créez un ConfigMap nommé opa-policy-add.

Utilisez ce ConfigMap pour définir votre politique OPA.

Créez un fichier YAML nommé opa-policy-add avec le contenu suivant :

apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy-add
  labels:
    ### You must configure the following label in the ConfigMap. Otherwise, the OPA policy that the ConfigMap defines cannot be dynamically updated. 
    openpolicyagent.org/policy: rego
data:
  policy.rego: |  ### The following code shows the definition of a sample policy. Define a policy based on your actual needs. 
    package istio.authz
    import input.attributes.request.http as http_request
    default allow = false
    allow {
        roles_for_user[r]
        required_roles[r]
    }
    roles_for_user[r] {
        r := user_roles[user_name][_]
    }
    required_roles[r] {
        perm := role_perms[r][_]
        perm.method = http_request.method
        perm.path = http_request.path
    }
    user_name = parsed {
        [_, encoded] := split(http_request.headers.authorization, " ")
        [parsed, _] := split(base64url.decode(encoded), ":")
    }
    user_roles = {
        "guest1": ["guest"],
        "admin1": ["admin"]
    }
    role_perms = {
        "guest": [
            {"method": "GET",  "path": "/productpage"},
        ],
        "admin": [
            {"method": "GET",  "path": "/productpage"},
            {"method": "GET",  "path": "/api/v1/products"},
        ],
    }

user_roles : attribue des rôles aux utilisateurs. Cet exemple attribue le rôle guest à guest1 et le rôle admin à admin1.
role_perms : définit les autorisations pour chaque rôle. Cet exemple permet au rôle guest d'accéder à l'application via le chemin /productpage, et au rôle admin d'accéder à l'application via les chemins /productpage et /api/v1/products.

Exécutez la commande suivante pour créer le ConfigMap :
```
kubectl apply -f opa-policy-add.yaml
```

Exécutez la commande suivante pour afficher le résultat de la propagation de la politique :
Le statut de la propagation est mis à jour dans les annotations du ConfigMap.
```
kubectl get configmap  opa-policy-add -o yaml  
```
Consultez le ConfigMap dans la sortie de la commande :
- Si la propagation réussit, les informations suivantes apparaissent dans le ConfigMap.
```
openpolicyagent.org/policy-status: '{"status":"ok"}'
```
- Si la propagation échoue, un message d'erreur correspondant s'affiche.

Étape 3 : Injecter un sidecar OPA

Déployez l'application exemple Bookinfo dans l'instance ASM et vérifiez l'injection d'un sidecar OPA dans chaque pod de l'application Bookinfo.

Déployez l'application exemple Bookinfo dans l'instance ASM. Pour plus d'informations, consultez la section Déployer une application dans une instance ASM.
Définissez les services virtuels Istio et un service de passerelle d'entrée selon vos besoins. Pour plus d'informations, consultez la section Routage du trafic basé sur la version avec Istio.
Vérifiez l'injection d'un sidecar OPA dans les pods de chaque application de l'application Bookinfo.
1. Connectez-vous à la Container Service Management Console.
2. Dans le volet de navigation de gauche, cliquez sur Cluster.
3. Sur la page Cluster List, cliquez sur le nom du cluster cible ou sur Details dans la colonne Actions.
4. Dans le volet de navigation de gauche de la page de gestion du cluster, choisissez Workload > Pods.
5. Sur la page Pods, sélectionnez default dans la liste déroulante Namespace et cliquez sur le nom du pod de l'application cible.
  
  Sur l'onglet Containers, confirmez l'injection d'un proxy sidecar (istio-proxy) et d'un sidecar OPA (opa-istio). Répétez cette vérification pour chaque pod d'application.

Étape 4 : Vérifier qu'une politique OPA implémente le contrôle d'accès comme prévu

Exécutez les commandes suivantes. Les résultats montrent que l'utilisateur guest1, doté du rôle guest, peut accéder à l'application via /productpage mais se voit refuser l'accès via /api/v1/products.
```
curl -X GET http://{{The IP address of the ingress gateway service}}/productpage --user guest1:password -I
```
La sortie suivante est attendue :
```
HTTP/1.1 200 OK
```
```
curl -X GET http://{{The IP address of the ingress gateway service}}/api/v1/products --user guest1:password -I
```
La sortie suivante est attendue :
```
HTTP/1.1 403 Forbidden
```
Exécutez les commandes suivantes. Les résultats montrent que l'utilisateur admin1, doté du rôle admin, peut accéder à l'application via les chemins /productpage et /api/v1/products.
```
curl -X GET http://{{The IP address of the ingress gateway service}}/productpage --user admin1:password -I
```
La sortie suivante est attendue :
```
HTTP/1.1 200 OK
```
```
curl -X GET http://{{The IP address of the ingress gateway service}}/api/v1/products --user admin1:password -I
```
La sortie suivante est attendue :
```
HTTP/1.1 200 OK
```
Les résultats précédents indiquent que la politique OPA définie implémente le contrôle d'accès comme prévu.

Étape 5 : Mettre à jour dynamiquement une politique OPA

Exécutez la commande suivante sur le cluster ACK pour mettre à jour le ConfigMap nommé opa-policy-add :

kubectl replace -n {The namespace where the ACK cluster resides} -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy-add
  labels:
    ### You must configure the following label in the ConfigMap. Otherwise, the OPA policy that the ConfigMap defines cannot be dynamically updated. 
    openpolicyagent.org/policy: rego
data:
  policy.rego: |  ### The following code shows the definition of a sample policy. Define a policy based on your actual needs. 
    package istio.authz
    import input.attributes.request.http as http_request
    default allow = false
    allow {
        roles_for_user[r]
        required_roles[r]
    }
    roles_for_user[r] {
        r := user_roles[user_name][_]
    }
    required_roles[r] {
        perm := role_perms[r][_]
        perm.method = http_request.method
        perm.path = http_request.path
    }
    user_name = parsed {
        [_, encoded] := split(http_request.headers.authorization, " ")
        [parsed, _] := split(base64url.decode(encoded), ":")
    }
    user_roles = {
        "guest1": ["guest", "admin"],
        "admin1": ["admin"]
    }
    role_perms = {
        "guest": [
            {"method": "GET",  "path": "/productpage"},
        ],
        "admin": [
            {"method": "GET",  "path": "/productpage"},
            {"method": "GET",  "path": "/api/v1/products"},
        ],
    }
EOF

user_roles : attribue des rôles aux utilisateurs. Cet exemple attribue à guest1 les rôles guest et admin, tandis que admin1 possède le rôle admin.
role_perms : définit les autorisations pour chaque rôle. Cet exemple permet au rôle guest d'accéder à l'application via le chemin /productpage, et au rôle admin d'y accéder via les chemins /productpage et /api/v1/products.

Exécutez la commande suivante pour afficher le résultat de la propagation de la politique :
Le statut de la propagation est mis à jour dans les annotations du ConfigMap.
```
kubectl get configmap  opa-policy-add -o yaml  
```
Consultez le ConfigMap dans la sortie de la commande :
- Si la propagation réussit, les informations suivantes apparaissent dans le ConfigMap.
```
openpolicyagent.org/policy-status: '{"status":"ok"}'
```
- Si la propagation échoue, un message d'erreur correspondant s'affiche.

Étape 6 : Vérifier qu'une politique OPA est mise à jour dynamiquement

Exécutez les commandes cURL suivantes. Les résultats indiquent que le rôle admin est attribué à l'utilisateur guest1. De plus, l'utilisateur guest1 dispose des autorisations nécessaires pour accéder à l'application en utilisant une URL contenant /productpage ou /api/v1/products.

curl -X GET http://{{The IP address of the ingress gateway service}}/productpage --user guest1:password -I

La sortie suivante est attendue :

HTTP/1.1 200 OK

curl -X GET http://{{The IP address of the ingress gateway service}}/api/v1/products --user guest1:password -I

La sortie suivante est attendue :

HTTP/1.1 200 OK

Avant la mise à jour de la politique OPA, l'utilisateur guest1 peut accéder à l'application en utilisant une URL contenant /productpage, mais pas /api/v1/products. Après la mise à jour de la politique OPA, l'utilisateur guest1 peut accéder à l'application en utilisant une URL contenant /productpage ou /api/v1/products. Le résultat indique que la politique OPA est mise à jour dynamiquement.