Utiliser Rego comme langage de règles générique

Les règles jouent un rôle essentiel dans toute organisation, mais leur signification peut varier considérablement selon le contexte. Dans cet article, nous entendons par règle les principes ou les idées qui guident les décisions d’une organisation.

Dans cet article, nous allons parler d’Open Policy Agent (OPA) et de son langage de règles, Rego, et voir comment les utiliser pour écrire une règle simple pour un microservice de paie.

Qu’est-ce qu’une règle ?

Dans les systèmes logiciels, les règles déterminent le fonctionnement d’un système. Les ordinateurs et les personnes s’appuient souvent sur des règles pour répondre à des questions telles que :

• L’utilisateur A est-il autorisé à modifier la configuration du service X ?

• Dans quel domaine devons-nous installer l’application X ?

• Quelles opérations se trouvent dans la mauvaise région géographique ?

La manière dont nous définissons et appliquons une règle dépend de plusieurs facteurs, comme la technologie concernée et la clarté de la règle. Dans certains cas, les règles relèvent de connaissances tacites : pour modifier un système ou comprendre son fonctionnement attendu, il faut alors consulter quelqu’un. Avec le temps, nous consignons les réponses, mais ces documents finissent par devenir obsolètes.

Une autre approche consiste à intégrer les règles directement dans les systèmes logiciels. Malheureusement, les règles évoluent avec le temps. Outre les mises à jour quasi constantes et la nécessité de former de nouveau les équipes, la modification de règles codées en dur nécessite une lecture globale et approfondie du code afin de comprendre ce qui doit changer. Le codage en dur rend les règles moins accessibles et plus longues à modifier.

Présentation d’Open Policy Agent

Les méthodes traditionnelles de gestion des règles offrent peu de garanties quant à leur application et sont coûteuses à maintenir. Open Policy Agent (OPA, prononcé « oh-pa ») est une solution moderne à ce problème.

OPA est un moteur de règles open source polyvalent qui permet de définir des règles dans différents systèmes, notamment les microservices, les passerelles API, les pipelines CI/CD et Kubernetes. Il permet d’écrire des règles sous forme de code, puis de les intégrer au processus de prise de décision.

Avec OPA, nous définissons des règles qui contrôlent le comportement d’un système. Ces règles répondent à des questions telles que :

• L’utilisateur A peut-il envoyer une requête GET à ce service ?

• Quels enregistrements l’utilisateur B est-il autorisé à consulter ?

• Sur quel serveur devons-nous déployer l’application X ?

Lorsque nous demandons une décision au sujet d’une règle, OPA analyse les règles et les données fournies pour générer une réponse, que le service à l’origine de la demande applique. Autrement dit, OPA prend la décision, tandis que les services intégrés à OPA se chargent de la mettre en œuvre. Le diagramme ci-dessous illustre le fonctionnement général d’OPA :

Pour comprendre le fonctionnement complet d’OPA, voyons comment il traite les requêtes dans un cas simple d’autorisation d’API, où nous définissons des règles pour autoriser ou refuser l’accès à certains services API. Lorsqu’un service reçoit une requête API, il envoie une requête à OPA. OPA compare alors cette requête aux règles et aux données existantes, puis renvoie une décision « autoriser » ou « refuser ». Enfin, le service applique la décision d’OPA en approuvant ou en rejetant la requête API.

Le langage de règles d’OPA : Rego

Nous écrivons les règles OPA dans un langage déclaratif de haut niveau appelé Rego (prononcé « ré-go »). Rego permet de créer facilement des règles évolutives pour différents types de services. Nous l’utilisons pour évaluer les données fournies en entrée et prendre les décisions correspondantes. N’oubliez pas que Rego n’est pas un langage de programmation permettant de créer des logiciels : c’est un langage déclaratif qui sert à écrire des règles, similaire à un langage de requête comme SQL.

Rego est un langage de règles polyvalent, ce qui signifie qu’il fonctionne avec différents systèmes. Il ne traite que des données JSON : nous pouvons donc écrire des règles pour n’importe quel service, à condition que les données nécessaires soient au format JSON. Rego nous permet ainsi de créer des règles qui s’appliquent à plusieurs systèmes.

Écrire votre première règle OPA

Écrivons maintenant une règle simple avec Rego et testons-la dans Rego Playground, une plateforme interactive en ligne. La règle détermine quels utilisateurs peuvent consulter les informations salariales d’un microservice de paie.

Pour commencer, supprimez tout le code existant dans le panneau principal de Rego playground, puis remplacez-le par le code suivant :

1package play 
2default allow = false
3# Users can only view their salary info
4allow = true { 
5    input.method = "GET" 
6    input.path = ["getSalary", user_id] 
7    input.user = user_id 
8}

Passons maintenant en revue l’extrait de code ci-dessus pour comprendre son fonctionnement :

• La première ligne de notre règle indique le nom du package. Chaque règle Rego possède un nom de package qui en définit la portée.

• La ligne suivante indique que la valeur allow est false par défaut.

• Le signe dièse (#) marque le début d’un commentaire et fournit une explication succincte du code.

• allow = true signifie que allow vaut true si toutes les expressions entre crochets sont true.

• Enfin, les expressions entre crochets indiquent que les requêtes sont autorisées si la méthode d’entrée est GET, si le chemin est /getSalary/user_id et si l’utilisateur est user_id. Notez que la variable input représente les données JSON que nous fournissons à Rego.

Rego Playground permet d’évaluer le code et de vérifier que la règle fonctionne comme prévu. Dans le panneau de saisie, nous pouvons donc simuler une requête en ajoutant le code suivant :

1{ 
2    "method": "GET", 
3    "path": ["getSalary","John"], 
4    "user": "John" 
5}

Voyons maintenant la réponse d’OPA à la requête ci-dessus en cliquant sur le bouton Evaluate. Le panneau de sortie devrait afficher un résultat semblable à celui-ci :

1{
2    "allow": true 
3}

Voici une capture de Rego Playground une fois toutes les étapes terminées :

Testons de nouveau notre règle en remplaçant user par Jane dans la requête : un utilisateur essaie alors de consulter les informations salariales d’une autre personne. En cliquant sur Evaluate, nous obtenons le résultat attendu suivant :

1{
2    "allow": false
3}

Nous allons ensuite modifier la règle afin que les employés du service financier puissent consulter les informations salariales de tous les utilisateurs. Pour cela, ajoutons le code suivant à la règle définie précédemment :

1#finance department workers can view every user's salary info
2allow = true { 
3    input.method = "GET" 
4    input.path = ["getSalary", user_id] 
5    finance[input.user] 
6} 
7finance = {"Ruth","Josh","Vivian"}

Dans le nouveau code de la règle, nous avons défini un objet finance et ajouté les noms de tous les employés du service financier.

Testons la règle en attribuant le même nom à user et à user_id (par exemple Joe). La règle doit renvoyer true. Remplaçons ensuite user par John, un employé du service financier, puis exécutons la règle. Elle doit à nouveau renvoyer true. Enfin, remplaçons user par un nom qui ne figure pas dans l’objet finance (par exemple Jane). Cette fois, la règle doit renvoyer false.

Récapitulatif

En combinant tous les extraits de code, nous obtenons notre nouvelle règle :

1package play 
2default allow = false
3# Users should have access to view their salary 
4allow = true { 
5    input.method = "GET" 
6    input.path = ["getSalary", user_id] 
7    input.user = user_id 
8}
9allow = true { 
10    input.method = "GET" 
11    input.path = ["getSalary", user_id] 
12    finance[input.user] 
13} 
14finance = {"John","Mary","Peter","Vivian"}

L’avenir de la personnalisation des règles

Maintenant que vous savez écrire des règles avec OPA et Rego, vous devez les maintenir et les analyser pour vous assurer qu’elles ne présentent aucune vulnérabilité. Avec Snyk Infrastructure as Code (Snyk IaC), qui s’appuie sur OPA pour analyser les règles, vous pouvez intégrer vos règles nouvelles et existantes à vos analyses à l’aide de quelques commandes simples. Consultez la documentation de Snyk IaC et notre article Développer des règles IaC personnalisées avec Snyk pour en savoir plus.

Pour commencer, créez gratuitement votre compte Snyk et repérez puis corrigez les erreurs de configuration IaC grâce aux contrôles de sécurité intégrés, aux garde-fous fondés sur des règles et aux conseils de correction adaptés aux développeurs, directement dans votre workflow.