Lors des phases de développement, c’est une partie souvent mise de côté voire oubliée : la sécurité. Cependant, c’est un point essentiel si ce n’est primordial.
En effet, contrôler l’accès aux données, aux codes, aux jobs est nécessaire afin qu’il n’y ait pas de modifications, dégradations ou encore vols. De plus, il faut aussi s’assurer que le projet reste accessible et pérenne dans le temps et ça tout au long de sa vie (et malgré le turnover dans les équipes).
Gérer les accès utilisateurs
Une solution simple devrait être mise en place au début de chaque projet : la création d’un user applicatif ainsi que de groupes ayant différents types d’accès aux données et aux jobs. Un user applicatif va nous servir à lancer les différents jobs directement en son nom. L’avantage premier est qu’il permettra de faire face aux changements (départ/arrivée) au sein de l’équipe de développement. Dans un second temps, il vous simplifiera aussi la lecture lorsque vous parcourrez les données ou logs créés. En effet, il sera plus simple de créer le lien entre les différents outputs et le projet qui en est la source (même si un outil de data lineage sera plus adapté dans cette situation).
Dans le même temps, la création de groupe vous aidera à avoir une gestion des accès plus efficace et simple. En effet, sur la majorité des solutions du marché, il est possible de créer des groupes et d’y associer différents droits à chacun des services/projets/données. La création de groupes est complémentaire à l’utilisation d’un user applicatif. Ainsi, l’arrivée ou le départ de collaborateurs sur le projet deviendra un non événement : il suffira de les ajouter ou supprimer du/des groupe(s).
Au sein de Saagie, la création d’un user applicatif se fait de la même manière qu’un simple utilisateur. L’idée ensuite est de créer un ou plusieurs groupes dans lesquelles le user applicatif et les différents intervenants du projet vont être ajoutés. Ces différents groupes reflèteront tous les niveaux d’accès au projet (jobs et données) : on peut imaginer avoir un premier groupe (développeur) qui pourrait à la fois accéder à la donnée en lecture mais aussi en écriture ainsi que créer et exécuter des jobs et un autre (viewer) qui aurait un droit en lecture seule à la fois sur les jobs et leurs statuts mais aussi sur les données produites.
Si vous ne disposez pas d’un outil tel que Saagie pour vous aider à gérer les utilisateurs et groupes, il est tout à fait possible de réaliser la même organisation sur un système Linux : charge à vous de créer les utilisateurs et groupes, et de leur donner les bons accès.
Contrôler l'accès aux données
En ce qui concerne le datalake, plusieurs approches d’organisation sont viables. Ici, nous allons nous focaliser sur l’une d’entre elles qui nous semble être la plus simple à mettre en place. Afin de cloisonner la donnée à la fois d’un point de vu stade de raffinage et projet/utilisation, nous vous conseillons de créer un répertoire à la racine de votre datalake contenant trois sous répertoires.
Vous devriez obtenir cette arborescence :
Une fois votre datalake organisé, il faudra mettre en place une politique de sécurité afin d’assurer que seuls les utilisateurs/groupes autorisés aient accès aux données contenues dans les dossiers projets. Pour ce faire, il existe un combo de plusieurs technologies:
- POSIX qui permet de sécuriser le file system avec la notion de groupes et d'utilisateurs. Cette technologie va couvrir 90% de nos besoins
- Quand les droits POSIX ne sont pas suffisants, les ACL vont nous venir en aide. Ils se basent sur la même logique "groupes / utilisateurs" que les droits POSIX mais nous apportent plus de possibilités qui vont vous être présentées dans la suite de cet article.
- Sentry va nous permettre de sécuriser les briques "SQL like" de notre Datalake. Hive et Impala nécessitent en effet une couche supplémentaire de sécurité afin d'assurer un accès aux données aux bonnes personnes. Sentry est assez similaire à ce qu'on peut retrouver dans toute base de données relationnelle : on va utiliser les keywords GRANT/REVOKE pour gérer les différents droits.
- Enfin Kerberos nous permet quant à lui de s'authentifier auprès de ces différents services. Cela ajoute donc une couche de sécurité. Nous n'allons pas détailler son fonctionnement ou comment le mettre en place dans cette article car c'est un point qui est lié aux Ops.
Nous allons désormais nous intéresser plus en détails aux 3 premiers points au travers d’exemples techniques.
Protocole POSIX
Deux possibilités existent pour appliquer les droits POSIX. Si on dispose d’une interface graphique comme HUE pour naviguer dans le DataLake, il est possible de passer par l’interface. Soit par ligne de commande.
Dans notre cas, nous voulons donner les droits au propriétaire et au groupe et ne donner aucun accès aux autres utilisateurs. Il faut donc appliquer les droits 770 sur toute l’arborescence.
Via HUE:
A noter: Le bit « Sticky » permet d’éviter la suppression du dossier ou du fichier en question par un autre personne que le propriétaire (même en ayant les droits via le groupe). Il faut donc l’appliquer sur les dossiers « raw », « intermediate » et « final ».
En ligne de commande pour affecter les mêmes droits que ci-dessus:
Si l’utilisateur ou le groupe n’est pas correctement appliqué:
Les protocoles ACLs
Dans certains cas, nous voulons accorder des droits différents à certains utilisateurs ou groupes. Par exemple si on souhaite qu’un groupe accède à un dossier en lecture et un autre en écriture, les droits POSIX ne sont pas suffisants et nous avons besoin des ACLs.
Pour affecter des droits ACL sur un dossier ou un fichier, contrairement à POSIX, on doit passer en ligne de commandes. Ces droits fonctionnent de la même manière que POSIX sauf que l’on peut affecter autant de droits sur autant d’utilisateurs et de groupes que souhaité.
En reprenant notre exemple où un dossier doit être en lecture pour un groupe et en écriture pour un autre:
Si l’on souhaite que la même configuration soit affecté à tous les sous dossier et fichier, il est possible de passer par les ACLs « default »:
Pour vérifier que les ACLs sont correctement affectés (-R est facultatif, il permet de voir les ACLs affectés à toute l’arborescence du dossier cible):
Pour des informations complète sur les ACLs et les droits POSIX, vous pouvez vous orienter vers la documentation officielle : ici !
Protocole Sentry
Dans le cas où l’on veut intégrer des technologies « SQL like » pour avoir un accès et une lisibilité plus faciles aux données, on va souvent s’orienter vers Hive, Impala ou Presto (les deux premières étant celles utilisés chez la majorité de nos clients).
Ces technologies nécessitent une couche supplémentaire pour sécuriser les données. En effet, les droits POSIX (lecture, écriture ou exécution) ne suffissent pas, on souhaite avoir une gestion plus fines des accès : accès qu’à certaines tables ou encore certaines colonnes.
Sentry va nous permettre de répondre à ce besoin.
Pour conclure !
Dans cet article, nous avons donc vu les bonnes pratiques afin d’assurer la sécurité de vos projets et de leurs données. Chacun de ces points sont faciles à mettre en œuvre et vous permettront de garder des accès sécurisés et pérennes tout au long de la vie de vos projets.
Un autre point important est d’assurer que le contexte d’exécution reste le même et soit isolé, c’est exactement ce que nous abordons dans cet article !
