Retour

Projet : Avenirs-ESR / ePortfolio.
Objet : Architecture logicielle du module Security - RBAC - Integration.

Révision : 1.0.1
Date : 15/06/2024
Auteur : A. Deman
Commentaire : Version reliée à la méthodologie de tests de charge

RBAC - Intégration du contrôle d’accès

Objectifs

  • Valider les modalités d’intégration du contrôle d’accès au niveau des différents composants.
  • Avoir une vision précise des coûts, principalement en terme de performances des différentes solutions.
  • Faire un focus particulier sur le coût lié à l’utilisation d’un API Manager.
  • Déterminer, réaliser et mesurer les optimisations nécessaires (cache, requêtes, base de données, etc.).

Solutions possibles, avantages et inconvénients

  • Intégration sous forme de librairie pour utiliser le contrôle d’accès directement dans les différents modules sans passer par l’API.
  • Utiliser directement l’API du contrôle d’accès sans passer par l’API Manager (APISIX).
  • Réaliser le contrôle au niveau de l’API Manager via une requête intermédiaire via une configuration de plugin.
Méthode Avantages Inconvénients
1. Générer une librairie - Performance optimale (beaucoup moins de latence réseau).
- Logique intégrée directement dans les modules.
- Autonomie des modules.
- Moins propre en termes d’architecture et de découpage par grands modules.
- Maintenance plus complexe (mise à jour dans tous les modules).
- Risque d’incohérence entre versions.
- Nécessite de donner un accès direct à la base de données du contrôleur d’accès, ce qui pose des problèmes de sécurité et de gestion des connexions.
2. Appel direct à l’API REST - Logique centralisée.
- Maintenance et mise à jour simplifiées.
- Modules moins volumineux.
- Latence accrue pour chaque requête.
3. Contrôle via l’API Manager (plugin) - Centralisation totale des règles d’accès.
- Aucun impact direct sur les modules.
- Possibilité de cache dans le plugin.
- Intégration native avec l’API Manager.
- Meilleure observabilité grâce au monitoring centralisé et aux outils d’analyse.
- Latence accrue pour chaque requête.
- Ajoute une complexité au niveau de l’API Manager (mais gérable via les conf de plugins réutilisables).


Notes:

  • En première approche, la solution de librairie est laissée de côté en raison des inconvénients citésdans le tableau.
  • Il s’agit donc d’effectuer une comparaison entre l’acces direct à l’API du contrôle d’accès et l’intégration au niveau de l’API Manager. La comparaison porte principalement sur le coût en terme de temps de réponse. La mise au point du plugin peut être difficile car il s’agit d’un script lua utilisé sous forme de fonction serverless. Cette version de plugin pourra être utilisée pouor la mise au point de cas spécifiques si nécessaire.
    L’utlisation de ce plugin pour la définition de routes est tres simple : voir l’exemple utilisé pour ce test.

Scénario utilisé

Les tests suivent la méthodologie de tests de charge mise en place. Ils s’appuient également sur une api minimalise de test :

  • Un end point qui s’interface directement avec le contrôle d’accès.
  • Un end point pour lequel le contrôle d’accès est remonté au niveau de l’API Manager .

A noter : le premier end point peut être testé également suivant 2 modalités, avec ou sans passage par l’API Manager (mais sans que l’API mananger ne réalise le contrôle d’accès).

Etapes

  1. Réaliser l’intégration sous forme de plugin avec APISIX
  2. Définir deux end-points de test un qui s’interface avec le contrôle d’access et l’autre non.
  3. Appliquer la méthodologie retenue pour les tests de charge.
  4. appliquer les tests pour les deux modalités d’intégration du contrôle d’accès.
  5. Réaliser des optimisations :
    • Ajouter du cache, notamment au niveau d’APISIX.
    • Eventuellement :
    • optimiser le code (revue de code ?).
    • Base de données (index ou autre).
      1. Rejouer les tests.
      2. Mesurer les gains éventuels.

    Premiers résultats

Ces premiers resultats sont effectués sur le serveur de dev : ressources limités, connexion par vpn, etc. Si possible, ils seront à confirmer sur une infrastructure plus proche de celle de production. Cependant, on peut tout de même comparer les deux approches puisque les tests sont réalisés dans les même conditions.
Le coût d’intégration au niveau de l’API MAnager est négiligeable sur une infrastructure peu chargée et semble même légèrement plus performant sur une infrastrcture chargée, comme le montrent les résultats avec le test set de 500 utilisateurs.

Le côut est probablement lié à l’évaluation du plugin permettant de réaliser l’intégration. La version du plugin utilisée pour ces tests est sous optimale : écriture de log et analyse de la réponse json plutot que de se baser sur le status http.
Son utilisation pour la définition de route au niveau de l’API Manager est, quand à elle, très simple : voir la route utilisée pour ces tests.

100 utilisateurs

  • 50 utilisateurs concurents

Contrôle d’accès au niveau de la méthode

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /node-api/ac-inlined 5405 0 56.5 39 195 196 22.53 0
  Aggregated 5405 0 56.5 39 195 196 22.53 0

(voir le rapport complet locust)

Contrôle d’accès au niveau de l’API Manager

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /apisix-gw/ac-in-apim 5428 0 57.99 41 285 196 22.65 0
  Aggregated 5428 0 57.99 41 285 196 22.65 0

(voir le rapport complet locust)



  • 100 Utilisateurs concurents

Contrôle d’accès au niveau de la méthode

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /node-api/ac-inlined 10797 0 59.47 38 468 196 45.01 0
  Aggregated 10797 0 59.47 38 468 196 45.01 0

(voir le rapport complet locust)

Contrôle d’accès au niveau de l’API Manager

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /apisix-gw/ac-in-apim 10873 0 59.59 40 331 196 45.33 0
  Aggregated 10873 0 59.59 40 331 196 45.33 0

(voir le rapport complet locust)



  • 150 Utilisateurs concurents

Contrôle d’accès au niveau de la méthode

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /node-api/ac-inlined 16151 0 63.4 37 518 196 67.34 0
  Aggregated 16151 0 63.4 37 518 196 67.34 0

(voir le rapport complet locust)

Contrôle d’accès au niveau de l’API Manager

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /apisix-gw/ac-in-apim 16218 0 62.63 39 639 196 67.61 0
  Aggregated 16218 0 62.63 39 639 196 67.61 0

(voir le rapport complet locust)



500 utilisateurs

  • 50 utilisateurs concurents

Contrôle d’accès au niveau de la méthode

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /node-api/ac-inlined 5226 0 78.68 40 852 196 21.83 0
  Aggregated 5226 0 78.68 40 852 196 21.83 0

(voir le rapport complet locust)

Contrôle d’accès au niveau de l’API Manager

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /apisix-gw/ac-in-apim 5417 0 58.02 40 352 196 22.6 0
  Aggregated 5417 0 58.02 40 352 196 22.6 0

(voir le rapport complet locust)



  • 100 utilisateurs concurents

Contrôle d’accès au niveau de la méthode

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /node-api/ac-inlined 10334 0 89.55 39 1234 196 43.09 0
  Aggregated 10334 0 89.55 39 1234 196 43.09 0

(voir le rapport complet locust)

Contrôle d’accès au niveau de l’API Manager

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /apisix-gw/ac-in-apim 10830 0 59.99 38 426 196 45.17 0
  Aggregated 10830 0 59.99 38 426 196 45.17 0

(voir le rapport complet locust)



  • 150 Utilisateurs concurents

Contrôle d’accès au niveau de la méthode

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /node-api/ac-inlined 15919 0 75.46 37 767 196 66.36 0
  Aggregated 15919 0 75.46 37 767 196 66.36 0

(voir le rapport complet locust)

Contrôle d’accès au niveau de l’API Manager

Type Name # Requests # Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s
GET /apisix-gw/ac-in-apim 16235 0 60.87 37 379 196 67.69 0
  Aggregated 16235 0 60.87 37 379 196 67.69 0

(voir le rapport complet locust)

Notes pour la faciliter la reprise des tests

( Penser à modifier le end point ici)
Retour