Creation d'une zone métier

Créer une zone métier

Une zone métier est définie par :

un projet rancher
une zone supplémentaire dans les labels du socle
des attributs supplémentaires spécifiques à la zone pour les utilisateurs de cette zone

Le point 1 est effectué par un Administrateur Système, les points 2 et 3 sont réalisés par un Administrateur Accès.

Créer un projet dans Rancher

Se connecter à Rancher avec un compte Administrateur Système

Accéder au cluster depuis la page d'accueil
Cliquer sur Cluster/Projects/Namespaces
Cliquer sur Create Project
Fournir un nom de projet et une description
Cliquer sur Create

Pour donner des droits à un administrateur coté métier (par exemple un administrateur d'application), l'administrateur système ajoute au projet l'utilisateur concerné (Sur la ligne du projet, cliquer sur les trois petits points à droite, puis Edit Config. on peux ajouter des membres au projet, en choisissant le type d'accès).

info

Pour connaitre l'id interne de la zone dans Rancher, il faut consulter la liste des Projets/Namespaces :

Cliquer sur Projects/Namespaces : les projets sont en bas de la liste.
Cliquer sur les 3 points à droite du nom du projet créé, puis sur edit YAML : parmi les paramètres, on retrouve le name :

Exemple : name: p-2z44v

Ajouter à ce projet deux namespaces :

<tenant_name>-dev. Le rendre privilégié en éditant sa configuration puis Pod Security Admission, Enforce et Save
<tenant_name>-dev-restricted

Ajouter une zone métier supplémentaire dans le référentiel des labels du socle

Pour cette étape, il faut bien avoir récupéré le nom technique du projet 'p-proj'.

Accéder à la base postgresql du référentiel 'kosmos_back' : avec pgAdmin (cluster kosmos)

Se connecter au cluster kosmos, consulter le base kosmos_back et la table label (View/Edit data -> All Rows)

Il existe 2 lignes : 1 pour 'organisation' (au sigulier) et une pour 'organisations' (au pluriel).

Modifier ces 2 lignes afin d'ajouter :

dans le champ "i18n" : ajouter le nom de la zone et son nom de projet sous la forme key,value pour obtenir par exemple : {"fr-FR": {"plural": "Zones", "values": [{"key": "p-rancherKey", "value": "DGA"},{"key": "p-proj", "value": "EXEMPLE"}], "singular": "Zone"}}
dans le champ "values" : le nom du projet ["p-rancherKey","p-proj"]

Faire le commit et vérifier en ré-affichant le contenu de la table.

Les 2 lignes : 1 pour 'organisation' et une pour 'organisations' doivent contenir la nouvelle zone.

remarque

Ci-dessous les instructions pour le faire en ligne de commande en accédant au namespace kosmos-sql (avec une commande kubectl exec dans le pod master):

kubectl exec -it -n kosmos-sql $(kubectl -n kosmos-sql get pod -l cnpg.io/instanceRole=primary -o name) -- psql -d kosmos_back
You are now connected to database "kosmos_back" as user "postgres".

Récupérer les valeurs existantes dans la table des 'label' pour l'id 'organisation' du tenant 'kosmos' :

Select i18n,values
FROM label
WHERE id='organisation' and tenant_id='kosmos';

Noter les valeurs obtenues pour les champs 'i18n' et 'values'.

On obtient par exemple, si 1 seula zone 'DGA' existe :

i18n vaut {"fr-FR": {"plural": "Zones", "values": [{"key": "p-rancherKey", "value": "DGA"}], "singular": "Zone"}}
values vaut ["p-rancherKey"]

Modifier ces valeurs comme suit :

ajout d'une valeur dans i18n avec key: nom technique de l'organisation (nom technique du projet rancher relevé à l'étape précédente) et value: nom d'affichage de l'organisation. Exemple: {"fr-FR": {"plural": "Zones", "values": [{"key": "p-rancherKey", "value": "DGA"},{"key": "p-mj49n", "value": "EXEMPLE"}], "singular": "Zone"}},
ajout dans values du nom technique de la nouvelle organisation. Exemple: ["p-rancherKey","p-mj49n"].

Exécuter les requêtes de mise à jour des 2 valeurs i18n et values du label 'organisation' :

UPDATE label  
SET
  i18n = jsonb_set(
    i18n,
    '{fr-FR,values}',
    (i18n->'fr-FR'->'values')::jsonb || '[{"key": "p-newkey", "value": "ToReplace"}]'::jsonb
  ),
  values = values || '["p-newkey"]'::jsonb
WHERE id='organisation' and tenant_id='kosmos';

Faire la même opération pour le label organisations (au pluriel) :

UPDATE label  
SET
  i18n = jsonb_set(
    i18n,
    '{fr-FR,values}',
    (i18n->'fr-FR'->'values')::jsonb || '[{"key": "p-newkey", "value": "ToReplace"}]'::jsonb
  ),
  values = values || '["p-newkey"]'::jsonb
WHERE id='organisations' and tenant_id='kosmos';

attention

Ne pas modifier les autres clés, et s'assurer qu'on ne modifie les valeurs des clés i18n et values que pour les labels organisation et organisations.
Il est INTERDIT de modifier/supprimer des valeurs/i18n existantes (on peut ajouter une Zone Métier, on ne peut pas en modifier/supprimer une existante).
Les champs i18n et values de organisation et organisations doivent être identiques après la modification.

Vérifier que les labels organisation et organisations ont été correctement modifiés.

SELECT *
FROM label;

Désigner son Administrateur Accès

Un premier Administrateur Accès se connecte à GDA.

Il accède à la gestion des utilisateurs pour affecter cette zone à un utilisateur qui est 'Administrateur Accès' : ce dernier devient l'Administrateur Accès de la nouvella zone (rappel, un utilisateur ne peut pas modifier ses propres droits, il doit donc désigner un camarade).

Ce nouvel Administrateur va alors poursuivre la configuration de la zone.

Créer une organisation et un utilisateur dans Gitea

Pour isoler les artefacts qui doivent rester propres à une zone, l'Administrateur Système, qui est administrateur de Gitea :

doit créer une organisation (e.g. <tenant_name>) dans gitea. L'accès à cette organisation sera gérée via la création de 'team' selon les fonctions standard de Gitea.
doit créer un utilisateur (e.g. <tenant_name>_ci) pour la CI/CD de cette zone et l'ajouter aux membres de l'organisation

Donner des droits dans Zot

Pour isoler les artefacts qui doivent rester propres à une zone, l'Administrateur Système va créer des comptes utilisateurs dédiés dans Zot. Voir dans la procédure dédiée.

Il va créer 1 ou plusieurs comptes ayant des droits sur des repository pour la zone.

Suivant les choix des organisations, il peut par exemple créer au moins 1 compte ayant les droits de lecture sur tout le contenu de Zot et d'écriture uniquement dans des repostory dédié à la zone. Il fournit ce compte à l'utilisateur métier qui en a besoin.

Penser à redémarrer zot une fois les configurations faites (kubectl rollout restart sts -n kosmos-dev-restricted zot-registry)

Créer des sous groupes dans Gitlab

Pour isoler les projets Gitlab des différentes zones métier, l'Administrateur Système, qui est administrateur de Gitlab, va créer des sous-groupes Gitlab :

dans le groupe "Bac a sable" (bas) : à destination des DataX et Développeurs qui travaillent dans le bac à sable
dans le groupe "Projets" : pour recevoir les projets des applications déployées dans l'EID ou la Prod

Et affecter le rôle "owner" sur ces sous-groupes à l'Administrateur Accès de la zone qui se chargera de donner ensuite les accès à d'autres personnes.

Rappel

L'Administrateur Accès doit s'être connecté une première fois à gitlab pour être connu dans gitlab.

Pour cela suivre les documentations :

L'Administrateur Accès pourra ensuite créer d'autres groupes ou sous-groupes dans sa zone métier, en fonction des besoins exprimés par les utilisateurs de sa zone.

Instancier les outils propres à la zone métier

Pour Dataiku, labelStudio et MLFlow, l'Administrateur Système instancie les outils nécessaires à la nouvella zone métier.

Il déploie chaque instance à l'aide des chart Helm disponibles, via Rancher. La procédure est celle décrite au paragraphe "chart Umbrella" des procédures d'installation des outils concernés.

Le déploiement va créer les groupes keycloak tels que précisés lors de l'installation (par exemple "labelStudio-zone1", "mlflow-zone1-admin"...), selon les droits fins permis pour chaque outil.

L'Administrateur Accès de la zone devra alors, dans GDA, affecter ce groupe aux utilisateurs qui en ont besoin (notamment l'Administrateur Données de la zone qui est chargé de configurer les accès aux datasets de la zone).

Si la plateforme est utilisée pour développer, si nécessaire un keycloak et un package-importer dédiés au tenant peuvent être déployés en utilisant les déploiements via Rancher.

Supprimer une zone

attention

La suppression d'une zone ne peut se faire que si elle n'est pas du tout utilisée !! Aucun utilisateur ou objet du socle ne doit être rattaché à cette zone. Il est nécessaire de bien mesurer les impacts avant de vouloir supprimer une zone.

Créer une zone métier​

Créer un projet dans Rancher​

Ajouter une zone métier supplémentaire dans le référentiel des labels du socle​

Désigner son Administrateur Accès​

Créer une organisation et un utilisateur dans Gitea​

Donner des droits dans Zot​

Créer des sous groupes dans Gitlab​

Instancier les outils propres à la zone métier​

Supprimer une zone​