EGI VOMS Client

Allgemeine Informationen

Über VOMS und VOs

Dies ist eine Ansible-Rolle, die VOMS-Clients konfiguriert. VOMS ist ein Webdienst zur Verwaltung der Mitgliedschaft von Virtuellen Organisationen (VOs). VOMS-Clients sind notwendig, um eine Autorisierung (in Form von kurzlebigen Proxys) für die Interaktion mit bestimmten Diensten basierend auf der VO-Mitgliedschaft zu erhalten. VOMS-Clients sind eine Reihe von Befehlszeilenwerkzeugen, die authentifizierte Anfragen an den entsprechenden VOMS-Server senden, um von diesen die Autorisierung anzufordern.

Um den VOMS-Client zu verwenden, benötigt man

• ein persönliches x.509-Zertifikat
• eine Registrierung in der VO, für die man eine Autorisierung erhalten möchte

VOMS-Clients werden typischerweise auf den Benutzeroberflächen oder Arbeitsknotenprofils installiert.

Konfiguration

Die Konfiguration der VOMS-Clients erfolgt mit wenigen Dateien:

1. .lsc-Dateien
2. vomses-Dateien

Siehe die VOMS-Dokumentation für detailliertere Informationen.

Für jede VO, mit der man interagieren möchte, muss die entsprechende Konfiguration vorhanden sein. Dies kann eine zeitaufwändige Aufgabe sein, insbesondere wenn ein Site-Administrator nicht weiß, welche VOs konfiguriert werden sollen.

Um das Leben zu erleichtern, verfolgen wir einen datengetriebenen Ansatz.

Die notwendigen Daten sind über die EGI Operations Portal API verfügbar, die in dieser Rolle als Datenquelle verwendet wird. Dies ermöglicht es uns, alle in dem Operations Portal registrierten VOs auf einmal zu konfigurieren. Es könnten zwei Ansätze zur Erstellung der Konfiguration verwendet werden:

1. Konfiguration aus Rohdaten, die zur Ansible-Laufzeit von Lavoisier abgerufen werden.
2. Konfiguration aus gefilterten Daten, die vor der Ansible-Laufzeit von Lavoisier abgerufen werden.

Im ersten Ansatz kann ein gut gestalteter json_query verwendet werden, um über die von Lavoisier zurückgegebenen Daten zu iterieren. Die Abfrage muss dabei die Komplexität und Struktur des von Lavoisier zurückgegebenen Datenobjekts widerspiegeln, das nicht garantiert eine konsistente Datenausgabe liefert. Im zweiten Ansatz wird ein viel einfacherer verwendet, um über ein zwischengespeichertes Datenobjekt zu iterieren, das gefiltert wurde, um Elemente auszuschließen, die nicht die relevanten Informationen enthalten. Diese zwischengespeicherten Daten können leicht mit einem einfachen Python-Skript - files/create_clean_vo_data.py - erstellt werden, das die Rollenvariablen liest und einen lokalen Daten-Cache erstellt. Das Datenformat wurde auf YAML gewählt, damit wir es ins Repository einfügen und Änderungen verfolgen können – das wäre mit JSON aufgrund der Zeilenmangel schwierig.

Wir haben uns für Letzteres entschieden (siehe 4215026e18c) aus folgenden Gründen:

1. Es ist einfacher, ein gut dokumentiertes Skript zu pflegen als eine komplexe JSON-Abfrage.
2. Es ist einfacher, ein gut dokumentiertes Skript zu lesen als eine komplexe JSON-Abfrage.
3. Wenn die Rolle als Abhängigkeit zu Playbooks hinzugefügt wird (was bereits der Fall sein wird, da die VOMS-Clients überall verwendet werden), müssen die Daten vorhanden sein.

Es gibt jedoch den Nachteil, dass die Daten im Repository schnell mit den tatsächlichen Daten auf Lavoisier unsynchron werden können. Dies kann entweder durch manuelles Bearbeiten des Caches durch Einzelpersonen oder durch das Versäumnis des Wartenden geschehen, das Skript bei Bedarf auszuführen. Der einzige Weg, dies zu überwinden, besteht darin, eine starke Testsuite aufrechtzuerhalten.

Aktualisieren der VO-Daten

Um die VO-Daten mit files/create_clean_vo_data.py zu aktualisieren, wird ein Authentifizierungstoken benötigt, um mit der EGI Operations Portal API zu interagieren.

Das Token kann generiert werden, indem man, während man über EGI Check-in authentifiziert ist, die Dokumentationsseite der Operations Portal API besucht, die Anweisungen auf der Seite befolgt und dann das Token in die Umgebung exportiert, bevor man files/create_clean_vo_data.py ausführt.

Es ist möglich zu überprüfen, ob das Token funktioniert, indem man einen curl-Aufruf testet:

# Exportieren des Operations Portal API-Tokens
$ export OPS_PORTAL_API_TOKEN='...'
# Testen eines API-Aufrufs mit 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"

Sobald der curl-Aufruf funktioniert, kann das bereitgestellte Skript verwendet werden:

# Exportieren des Operations Portal API-Tokens
$ export OPS_PORTAL_API_TOKEN='...'
# Aktualisieren der VO-Daten
$ ./files/create_clean_vo_data.py

Testen

Die Rolle wird mit molecule für folgende Szenarien getestet:

• default (getestet mit TestInfra)

Die Tests umfassen Unit- und Integrationstests, aber keine funktionalen Tests, da ein persönliches Zertifikat zum Verwenden des VOMS-Clients erforderlich ist. Dabei sind spezielle Tests enthalten:

• Vorhandensein von Binärdateien
• Vorhandensein von Konfigurationsverzeichnissen
• Inhalt von Konfigurationsdateien für ausgewählte VOs

Anforderungen

Siehe requirements.txt.

Rollenvariablen

Die Rollenvariablen, die in defaults/main.yml gespeichert sind, umfassen:

• prerequisites - die erforderlichen Pakete basierend auf dem Betriebssystem
• voms_dir, vomses_dir - Verzeichnisstandorte auf dem Ziel-Host, die die VOMS-Informationen enthalten
• lavoisier - die Endpunkte des Lavoisier-Frameworks, die zum Extrahieren der Daten erforderlich sind, um die Konfigurationsdateien zu füllen.

Es ist nicht notwendig, die Standardvariablen zu ändern.

Abhängigkeiten

Abhängigkeiten sind nicht explizit in den Metadaten angegeben, aber diese Rolle hängt von der UMD-Rolle ab:

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

Beispiel-Playbook

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

Lizenz

Apache-2.0

Autorinformationen

Siehe AUTHORS.md