Cliente EGI VOMS

Información general

Acerca de VOMS y VOs

Este es un rol de Ansible que configura clientes VOMS. VOMS es un servicio web para gestionar la membresía de Organizaciones Virtuales. Los clientes VOMS son necesarios para obtener autorización (en forma de proxies de corta duración) para interactuar con servicios específicos, basados en la membresía de VO. Los clientes VOMS son un conjunto de utilidades de línea de comandos que envían solicitudes autenticadas al servidor VOMS relevante para solicitar autorización.

Para usar el cliente VOMS, una persona necesita

• tener un certificado personal x.509
• estar registrado en la VO para la que desea obtener autorización

Normalmente, los clientes VOMS se instalan en el perfil de Interfaz de Usuario o Nodo de Trabajo.

Configuración

La configuración de los clientes VOMS se realiza con algunos archivos:

1. Archivos .lsc
2. Archivos vomses

Consulte la documentación de VOMS para más información detallada.

Para cada VO con la que desee interactuar, es necesario tener la configuración relevante. Esto puede ser una tarea que consume bastante tiempo, especialmente en casos donde un administrador del sitio no sabe de antemano qué VOs configurar.

Para hacer la vida más fácil, tomamos un enfoque basado en datos.

Los datos necesarios están disponibles a través de la API del Portal de Operaciones de EGI, que se utiliza en este rol como fuente de datos. Esto nos permite configurar todas las VOs registradas en el Portal de Operaciones de una vez. Se pueden emplear dos enfoques para generar la configuración:

1. configuración a partir de datos sin procesar extraídos de Lavoisier en el tiempo de ejecución de Ansible
2. configuración a partir de datos filtrados extraídos de Lavoisier antes del tiempo de ejecución de Ansible.

En el primer enfoque, se puede utilizar un json_query bien diseñado para iterar sobre los datos devueltos por Lavoisier. La consulta, en este caso, debe reflejar la complejidad y estructura del objeto de datos devuelto por Lavoisier, que no se puede asumir que devuelva una matriz de datos consistentes. En el segundo enfoque, se utiliza un método mucho más simple para iterar sobre un objeto de datos en caché, que ha sido filtrado para excluir elementos que no contienen la información relevante. Estos datos en caché se pueden crear fácilmente mediante un simple script en Python - files/create_clean_vo_data.py que lee las variables del rol y crea una caché local de datos. El formato de datos se eligió como YAML para poder agregarlo al repositorio y hacer seguimiento de los cambios, lo cual sería complicado con JSON, debido a la falta de líneas.

Hemos optado por el segundo (ver 4215026e18c) por las siguientes razones:

1. Es más fácil mantener un script bien documentado que una consulta JSON compleja.
2. Es más fácil leer un script bien documentado que una consulta JSON compleja.
3. Si el rol se agrega como una dependencia a los playbooks (como sin duda será el caso, ya que los clientes VOMS se utilizan en muchos lugares), los datos necesitan estar presentes.

Sin embargo, hay una desventaja en que los datos en el repositorio pueden desincronizarse rápidamente con los datos reales en Lavoisier. Esto puede suceder ya sea porque individuos editan la caché manualmente, o porque el mantenedor no ejecuta el script cuando es necesario. La única forma de superar esto es mantener un fuerte conjunto de pruebas.

Actualización de los datos de VO

Para actualizar los datos de VO utilizando files/create_clean_vo_data.py, se requiere un token de autenticación para interactuar con la API del Portal de Operaciones de EGI.

El token puede generarse accediendo, mientras se está autenticado a través de EGI Check-in, a la página de documentación de la API del Portal de Operaciones, seguir las instrucciones de la página, y luego exportar el token al entorno antes de ejecutar files/create_clean_vo_data.py.

Es posible probar que el token está funcionando utilizando una llamada de curl:

# Exportando el token de la API del Portal de Operaciones
$ export OPS_PORTAL_API_TOKEN='...'
# Probando una llamada a la API usando 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"

Una vez confirmado que la llamada curl funciona, es posible usar el script proporcionado:

# Exportando el token de la API del Portal de Operaciones
$ export OPS_PORTAL_API_TOKEN='...'
# Actualizando los datos de VO
$ ./files/create_clean_vo_data.py

Pruebas

El rol se prueba con molecule para los siguientes escenarios:

• default (probado con TestInfra)

Las pruebas cubren pruebas unitarias e de integración, pero no pruebas funcionales, ya que se necesita un certificado personal para usar el cliente VOMS. Las pruebas específicas incluidas son:

• presencia de ejecutables binarios
• presencia de directorios de configuración
• contenidos de archivos de configuración para VOs seleccionadas

Requisitos

Consulte requirements.txt.

Variables del rol

Las variables del rol que se mantienen en defaults/main.yml incluyen:

• prerequisites - los paquetes requeridos según el sistema operativo
• voms_dir, vomses_dir - ubicaciones de directorios en el host de destino que contienen la información de voms
• lavoisier - los puntos finales del marco lavoisier necesarios para extraer los datos necesarios para llenar los archivos de configuración.

No es necesario cambiar las variables predeterminadas.

Dependencias

Las dependencias no están declaradas explícitamente en los metadatos, pero este rol depende del rol UMD:

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

Ejemplo de playbook

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

Licencia

Apache-2.0

Información del autor

Consulte AUTHORS.md