Gestion des accès : comment Grab est passé des rôles aux attributs

Grab a greffé à son infra Kafka un contrôle d’accès basé sur les attributs (ABAC), en remplacement du contrôle basé sur les rôles (RBAC).

Faire en sorte que le plan de contrôle Kafka surveille le flux IAM ? Grab le présentait comme une de ses principales perspectives il y a quelques mois de cela. En toile de fond, la transition vers une logique de contrôle d’accès basé non plus sur les rôles (RBAC), mais sur les attributs (ABAC).

Cette démarche a permis à l’entreprise singapourienne de commerce en ligne – qu’on connaît essentiellement pour ses services concurrents de ceux d’Uber – de supprimer diverses tâches manuelles et de renforcer la gouvernance de ses ressources.

Chez Grab, la gestion des topics Kafka est décentralisée. Chaque équipe peut en créer, en modifier et en supprimer. Le plan de contrôle permet d’assurer que ces opérations ne sont effectuées que par des parties autorisées.

Avec la logique RBAC, les rôles, les ressources, les permissions, les actions et les relations entre eux devaient être définis dans l’IAM. Une approche qui présentait plusieurs inconvénients :

– Augmentation du nombre d’éléments nécessaires à la gestion des accès
– Nécessité d’une approbation par le manager pour tous les nouveaux membres d’équipes (certains rôles étant par ailleurs à renouveler tous les 90 jours)
– Absence de tri des membres actifs au sein des groupes (des ingénieurs ont alors accès à des ressources dont ils n’ont pas besoin)

Le SIRH comme source de vérité

Avec la méthode ABAC, tout nouveau membre hérite des mêmes droits que les autres membres de son équipe, sans processus d’approbation manuelle. Cela implique de définir, d’une part, des attributs utilisateur (en fonction du département et de l’équipe ; données synchronisées avec le SIRH). De l’autre, des attributs de ressources.

L’opération de provisionnement étant authentifiée, le plan de contrôle Kafka sait qui envoie les requêtes et quel est leur objet. Aussi, on peut déterminer les attributs de ressources à partir des attributs utilisateur – et étiqueter les ressources en conséquence.
Pour les ressources existantes, c’est plus compliqué : il a fallu adapter les tags, historiquement gérés par une équipe plate-forme centralisée. Le processus, qui a nécessité trois mois, a permis d’aller vers un modèle en self-service. Les ressources non identifiées se sont vu attribuer le tag lost-and-found, les équipes pouvant alors les réclamer.

Open Policy Agent complète l’attirail, en tant que moteur d’évaluation des requêtes.

Lors de l’authentification, le plan de contrôle récupère un token dans l’IAM. Les requêtes sur les topics embarquent ce token, dont on extrait les attributs utilisateur en vue de l’étape d’autorisation. Celle-ci passe par OPA, auquel on communique les attributs utilisateur, les attributs de ressources et les métadonnées de la requête API (méthode, endpoint). Avec ce système, il n’y a pas besoin d’un paramétrage supplémentaire lorsqu’un utilisateur change d’équipe.

Un repo GitLab spécifique aux politiques ABAC

La gestion des politiques de contrôle d’accès se fait dans un dépôt GitLab spécifique. Les journaux de décision d’OPA demeurent 5 jours dans Kibana à des fins de débogage. Ils restent ensuite 28 jours supplémentaires sur S3.

Outre la réduction du nombre de ressources à gérer, l’approche ABAC a allégé l’IAM (suppression de 200 rôles, 200 permissions et près de 3000 ressources non utilisées). Elle a aussi réduit les temps d’attente liés aux processus d’approbation manuelle. Et optimisé la gouvernance des ressources comme des coûts, à travers un étiquetage standardisé. En contrepartie, il est nécessaire de maintenir les tags à jour, sans quoi des accès peuvent se perdre. La connexion du plan de contrôle Kafka au flux IAM doit précisément aider à la mise à jour régulière des attributs.