GitLab

@mutualisation-sysma

Bonjour à tous les mutualisés.

Pour faciliter notre travail,ce ticket doit traiter des users et groupes des bases postgres uniquement. Cette réflexion concerne donc les modalités d'accès à la base de données via un client sig comme QGIS ou via un client SQL.

_De manière générale : 1 ticket = un sujet (ce qui se traduit chez nous par : une tache à résoudre => puis fermeture du ticket). _

De nombreux tickets évoquent un besoin d'avoir plus de choix de user pour les accès à vos données de Postgres (#58 (closed),#160 (closed),#165). Les besoins sont variés et il me semble impossible de prévoir tous les cas de figure et de répondre aux besoins actuels et futurs de tous.

Voici mes propositions

Proposition 1 (ce n'est pas ma préférée):

• ajout des users pg suivants :
  • ***_lecture_sysma_export_r // droits du groupe lecture + accès en lecture à sysma_export_layer et sysma_altlas
  • ***_stucture_sysma_export_r // droits du groupe structure + accès en lecture à sysma_export_layer et sysma_altlas
  • ***_pesta_01 // user en attente (juste un droite de connexion à votre db) utilisable pour paramétrer un accès particulier pour un prestataire

Proposition 2 (celle que je préfère):

• création des nouveaux users suivants :

• ***_structure_01 , ***_structure_02, ***_structure_03 (configuration par défaut et irrévocable : droits du groupe structure)
• ***_presta_01, ***_presta_02, ***_presta_03 (configuration par défaut et irrévocable : droit de connexion à votre base)
• ***_fdw : user disponible pour connecter votre propre serveur pg en lecture sur l'instance mutualisée avec mise en place de Foreign data wrappers (configuration par défaut et irrévocable : droit de connexion à votre base)

Ensuite, votre compte admin postgres pourrait ajouter/retirer des droits de lectures aux différents schemas en attribuant à ces users les droits de groupe de type ***_[nom_de_schema]_r. L'intérêt , c'est que vous avez plus de flexibilité pour configurer ces users en fonction de vos besoins particuliers. A noter qu'un compte user peut être donné à plusieurs agents. Les comptes ***_structure_0X peuvent-être considérés comme des types de compte (type 01 à 03) avec différents droits d'accès que vous maitrisez.

Pour l'instant je limite le nombre de nouveaux users à cette liste. En effet, la gestion des users est assez chronophage pour moi car, pour chaque user, je dois faire plusieurs manipulations jusqu'à la transmission des mdp à vos structures, plus il y a de user, plus cela me prend du temps.

Je suis malheureusement obligé de restreindre les possibilités pour vos bases mutualisées pour des raisons de maintenabilité.

Infos complémentaires

• refonte de la doc expliquant les droits postgres que les instances mutualisées dans un espace accessible uniquement aux mutualisés

• Note réflexion que nous avons eu avec @acoudart pour le CD 35 par exemple : Pour ceux qui souhaiteraient avoir plus de liberté (gestion fine des users et filtrage des accès aux données), il faudrait que vous ayez votre propre serveur postgres (SERVERUR_B) qui se connecte (il existe les FDW pour cela) à la base mutualisé (SERVEUR_A). Depuis le SERVUER_B qui vous appartient, vous pouvez attribuer autant de droits que vous voulez, créer des vues par user / ou groupes ...

J'attends vos retours/idées complémentaires sur ce sujet avant d'opérer ces ajouts (merci de préciser votre structure dans les échanges) , j'avoie que parfois je m'y retrouve pas tout le temps avec juste vos identifiants gitab.

note : Idéalement ce serait super de compléter dans votre profile https://gitlab.sevre-nantaise.com/-/profile la case 'organisation'.