Client VOMS EGI

Informations générales

À propos de VOMS et des VOs

Ceci est un rôle Ansible qui configure les clients VOMS. VOMS est un service web pour gérer l'adhésion aux Organisations Virtuelles. Les clients VOMS sont nécessaires pour obtenir une autorisation (sous forme de proxies de courte durée) pour interagir avec des services spécifiques, basés sur l'adhésion à une Organisation Virtuelle. Les clients VOMS sont un ensemble d'utilitaires en ligne de commande qui envoient des demandes authentifiées au serveur VOMS concerné pour demander une autorisation.

Pour utiliser le client VOMS, une personne doit

• avoir un certificat x.509 personnel
• être enregistrée dans l'Organisation Virtuelle pour laquelle elle souhaite obtenir une autorisation

Les clients VOMS sont généralement installés sur les profils d'Interface Utilisateur ou de Noeud de Travail.

Configuration

La configuration des clients VOMS se fait à l'aide de quelques fichiers :

1. Fichiers .lsc
2. Fichiers vomses

Voir la documentation VOMS pour plus d'informations détaillées.

Pour chaque Organisation Virtuelle avec laquelle vous souhaitez interagir, la configuration pertinente doit être en place. Cela peut être une tâche assez chronophage, surtout dans les cas où un administrateur de site ne sait pas à l’avance quelles VOs configurer.

Pour rendre la vie plus facile, nous adoptons une approche basée sur les données.

Les données nécessaires sont disponibles via l'API du Portail des Opérations EGI, qui est utilisée dans ce rôle comme source de données. Cela nous permet de configurer toutes les VOs enregistrées dans le Portail des Opérations en une seule opération. Deux approches peuvent être adoptées pour générer la configuration :

1. configuration à partir de données brutes récupérées de Lavoisier au moment de l'exécution d'Ansible
2. configuration à partir de données filtrées récupérées de Lavoisier avant l'exécution d'Ansible.

Dans la première approche, une requête json_query bien conçue pourrait être utilisée pour itérer sur les données retournées par Lavoisier. La requête dans ce cas doit refléter la complexité et la structure de l'objet de données retourné par Lavoisier, qui ne peut pas être supposé renvoyer un tableau de données cohérentes. Dans la seconde approche, une méthode beaucoup plus simple est utilisée pour itérer sur un objet de données mis en cache, qui a été filtré pour exclure les éléments ne contenant pas les informations pertinentes. Ces données mises en cache peuvent être facilement créées par un simple script python - files/create_clean_vo_data.py qui lit les variables du rôle et crée un cache local de données. Le format de données a été choisi comme YAML afin que nous puissions l'ajouter au dépôt et suivre les modifications - cela serait difficile avec JSON, en raison du manque de lignes.

Nous avons opté pour la seconde (voir 4215026e18c) pour les raisons suivantes :

1. Il est plus facile de maintenir un script bien documenté qu'une requête json complexe.
2. Il est plus facile de lire un script bien documenté qu'une requête json complexe.
3. Si le rôle est ajouté comme dépendance à des playbooks (ce qui sera certainement le cas, puisque les clients VOMS sont utilisés partout), les données doivent être présentes.

Cependant, il y a un inconvénient : les données dans le dépôt peuvent rapidement devenir obsolètes par rapport aux données réelles sur Lavoisier. Cela pourrait se produire soit par des modifications manuelles du cache, soit parce que le responsable ne lance pas le script quand c'est nécessaire. La seule façon de surmonter cela est de maintenir une solide suite de tests.

Mise à jour des données VO

Pour mettre à jour les données VO en utilisant files/create_clean_vo_data.py, un jeton d'authentification est requis pour interagir avec l'API du Portail des Opérations EGI.

Le jeton peut être généré en accédant, tout en étant authentifié via EGI Check-in, à la page de documentation de l'API du Portail des Opérations, en suivant les instructions de la page, puis en exportant le jeton dans l'environnement avant d'exécuter files/create_clean_vo_data.py.

Il est possible de tester que le jeton fonctionne en utilisant un appel curl :

# Exportation du jeton API du Portail des Opérations
$ export OPS_PORTAL_API_TOKEN='...'
# Test d'un appel API avec curl
$ curl -X GET "https://operations-portal.egi.eu/api/vo-voms/json" \
    -H "Accept: application/json" \
    -H "X-API-Key: $OPS_PORTAL_API_TOKEN"

Une fois que l'appel curl est confirmé comme fonctionnant, il est possible d'utiliser le script fourni :

# Exportation du jeton API du Portail des Opérations
$ export OPS_PORTAL_API_TOKEN='...'
# Mise à jour des données VO
$ ./files/create_clean_vo_data.py

Tests

Le rôle est testé avec molecule pour les scénarios suivants :

• default (testé avec TestInfra)

Les tests couvrent les tests unitaires et d'intégration, mais pas les tests fonctionnels, car un certificat personnel est nécessaire pour utiliser le client VOMS. Les tests spécifiques inclus sont :

• présence d'exécutables binaires
• présence de répertoires de configuration
• contenus des fichiers de configuration pour les VOs sélectionnées

Exigences

Voir requirements.txt.

Variables de rôle

Les variables de rôle conservées dans defaults/main.yml incluent :

• prerequisites - les packages requis sur une base OS
• voms_dir, vomses_dir - emplacements des répertoires sur l'hôte cible qui contiennent les informations voms
• lavoisier - les points de terminaison du cadre lavoisier nécessaires pour extraire les données nécessaires à la remplissage des fichiers de configuration.

Il n'est pas nécessaire de changer les variables par défaut.

Dépendances

Les dépendances ne sont pas explicitement déclarées dans les métadonnées, mais ce rôle dépend du rôle UMD :

- { role: EGI-Foundation.umd, release: 4 }

Exemple de Playbook

- hosts: servers
  roles:
    - { role: EGI-Foundation.umd, release: 4 }
    - { role: EGI-Foundation.voms-client }

Licence

Apache-2.0

Informations sur l'auteur

Voir AUTHORS.md