Sécurité API améliorée : contrôle d’accès granulaire en utilisant OPA et Kong Gateway

Tutoriels
PostgreSQL

Kong Gateway est une passerelle d’API open source qui assure que seules les demandes correctes sont traitées en gérant la sécurité, la limitation de débit, le logging et plus encore. OPA (Open Policy Agent) est un moteur de politiques open source qui prend en charge vos décisions de sécurité et d’accès. Envisagez-le comme une entité qui découple l’application des politiques, de sorte que vos services n’ont pas à s’inquiéter de l’application des règles. Au lieu de cela, c’est OPA qui effectue les traitements avec son langage Rego, évaluant les politiques across APIs, microservices, ou même Kubernetes. Il est flexible, sécurisé et permet de mettre à jour les politiques facilement. OPA fonctionne en évaluant trois éléments clés : l’entrée (données en temps réel telles que les demandes), les données (informations externes telles que les rôles d’utilisateurs) et la politique (la logique dans Rego qui décide de « permettre » ou de « refuser »). Ensemble, ces composants permettent à OPA de maintenir votre sécurité en bonne santé tout en simplifiant et en uniformisant les choses.

Quelles sont les missions ou les problèmes que nous cherchons à accomplir ou à résoudre ?

Fréquemment, les données dans l’ANP sont comme un vieil ami fidèle — statiques ou lentement changeantes. Elles sont utilisées en parallèle avec les données d’entrée en constante évolution pour prendre des décisions intelligentes. Mais imaginez un système avec un réseau déployé de microservices, de nombreux utilisateurs et une base de données massive comme PostgreSQL. Ce système gère un volume élevé de transactions toutes les secondes et doit conserver sa vitesse et sa throughput sans s’épingler.

Le contrôle d’accès à la fine granularité dans ce système est difficile, mais avec l’ANP, vous pouvez décharger le travail ardu de vos microservices et le gérer au niveau du passerelle. En équipe avec le passerelle d’API Kong et l’ANP, vous obtenez à la fois une throughput de haut niveau et un contrôle d’accès précis.

Comment maintenez-vous les données utilisateur précises sans ralentir les choses ? Frapper constamment cette base de données PostgreSQL pour récupérer des millions d’enregistrements est à la fois coûteux et lent. Atteindre à la fois précision et vitesse exige généralement des compromis entre les deux. Faisons-nous une balance pratique en développant un plugin personnalisé (au niveau du passerelle) qui charge fréquemment et cache localement les données pour que l’ANP les utilise dans l’évaluation de ses politiques.

Démo

Pour la démonstration, j’ai configuré des données d’exemple dans PostgreSQL, contenant des informations sur les utilisateurs telles que le nom, l’email et le rôle. Lorsqu’un utilisateur essaye d’accéder à un service via une URL spécifique, OPA évalue si la requête est autorisée. La politique Rego vérifie l’URL de la requête (ressource), la méthode et le rôle de l’utilisateur, puis retourne vrai ou faux en fonction des règles. Si vrai, la requête est autorisée à passer ; si faux, l’accès est refusé. Jusqu’à maintenant, c’est une configuration directe. Allons-y maintenant sur le plugin personnalisé. Pour une meilleure compréhension de son implémentation, veuillez vous référer au diagramme ci-dessous.

Lorsqu’une requête traverse le proxy Kong, le plugin personnalisé de Kong est déclenché. Le plugin récupère les données requises et les passe à OPA en même temps que l’input/query. Cette récupération de données comporte deux parties : l’une consiste à chercher dans Redis pour trouver les valeurs requises et, si elles sont trouvées, à les passer à OPA ; sinon, il faut effectuer une requête supplémentaire sur Postgres pour obtenir les données et les mettre en cache dans Redis avant de les passer à OPA. Nous pouvons revoir ça lorsque nous exécutons les commandes dans la prochaine section et observer les journaux. OPA prend une décision (en fonction de la politique, de l’input et des données) et si cela est autorisé, Kong procède à envoyer la requête vers l’API. En utilisant cette approche, le nombre de requêtes vers Postgres est considérablement réduit, tout en conservant des données disponibles pour OPA relativement précises et en préservant une latence basse.

Pour commencer à construire un plugin personnalisé, nous avons besoin d’un fichier handler.lua où la logique centrale du plugin est implémentée et un fichier schema.lua qui, comme son nom l’indique, définit le schéma pour la configuration du plugin. Si vous commencez à apprendre comment écrire des plugins personnalisés pour Kong, veuillez vous référer à ce lien pour plus d’information. La documentation explique également comment emballer et installer le plugin. Allons-y et comprenons la logique de ce plugin.

Le premier pas de la démo serait d’installer OPA, Kong, Postgres et Redis sur votre configuration locale ou sur n’importe quelle configuration cloud. Veuillez cloner vers ce dépôt.

Examinez le fichier docker-compose.yaml qui contient les configurations définies pour déployer les quatre services ci-dessus. Observez les variables d’environnement Kong pour voir comment le plugin personnalisé est chargé.

Exécutez les commandes suivantes pour déployer les services :

Dockerfile

 

Une fois que nous avons vérifié que les conteneurs sont en cours d’exécution, Kong manager et OPA sont disponibles sur les points de terminaison respectifs https://localhost:8002 et https://localhost:8181, comme illustré ci-dessous :

Créez un service de test, une route et ajoutez notre plugin Kong personnalisé à cette route en utilisant la commande suivante :

Shell

La politique OPA, définie dans le fichier authopa.rego, est publiée et mise à jour dans le service OPA à l’aide de la commande suivante :

Shell

Cette politique de base autorise l’accès aux demandes utilisateurs uniquement si l’utilisateur accède au chemin /demo avec la méthode GET et possède le rôle de "Modérateur". Des règles supplémentaires peuvent être ajoutées à mesure des besoins pour personnaliser le contrôle d’accès en fonction de différents critères.

JSON

Maintenant, l’installation est prête, mais avant de tester, nous avons besoin de某些es données de test pour ajouter dans Postgres. J’ai ajouté certaines données exemples (nom, courriel et rôle) pour quelques employés, comme illustré ci-dessous (veuillez vous référer au PostgresReadme).

Voici un exemple de demande réussie et échouée :

Maintenant, pour tester la fonctionnalité principale de ce module personnalisé, faisons deux demandes consécutives et vérifions les journaux pour observer comment se produit l’extraction des données.

Voici les journaux :

JSON

 

Les journaux montrent que pour la première demande, lorsque les données ne sont pas dans Redis, les données sont extraites de Postgres et mises en cache dans Redis avant d’être envoyées à OPA pour évaluation. Dans la demande suivante, comme les données sont disponibles dans Redis, la réponse sera beaucoup plus rapide.

Conclusion

En conclusion, en combinant le Gateway Kong avec l’OPA et en implémentant le module personnalisé avec un cache Redis, nous avons effectivement équilibré précision et vitesse pour le contrôle d’accès dans des environnements à haut débit. Le module réduit le nombre de requêtes coûteuses vers Postgres en mettant en cache les rôles d’utilisateurs dans Redis après la première requête. Dans les demandes suivantes, les données sont récupérées depuis Redis, réduisant显著ement la latence tout en conservant des informations sur les utilisateurs précises et à jour pour les évaluations de politiques OPA. Cette approche assure que le contrôle d’accès à la fine graine est traité efficacement au niveau du gateway sans sacrifier la performance ou la sécurité, ce qui en fait une solution idéale pour élargir les microservices tout en enforcing des politiques d’accès précises.

Source:
https://dzone.com/articles/enhanced-api-security-fine-grained-access-control