Klient EGI VOMS

Informacje ogólne

O VOMS i VO

Jest to rola Ansible, która konfiguruje klientów VOMS. VOMS to usługa internetowa do zarządzania członkostwem w Wirtualnych Organizacjach (VO). Klienci VOMS są potrzebni do uzyskania autoryzacji (w formie krótkoterminowych proxy) do interakcji z określonymi usługami, w zależności od członkostwa w VO. Klienci VOMS to zestaw narzędzi wiersza poleceń, które wysyłają uwierzytelnione żądania do odpowiedniego serwera VOMS w celu uzyskania autoryzacji.

Aby używać klienta VOMS, indywidualna osoba musi:

• posiadać osobisty certyfikat x.509
• być zarejestrowana w VO, dla którego chce uzyskać autoryzację

Klienci VOMS zazwyczaj są instalowani na profilach Interfejsu Użytkownika lub Węzła Roboczego.

Konfiguracja

Konfiguracja klientów VOMS odbywa się za pomocą kilku plików:

1. pliki .lsc
2. pliki vomses

Zobacz dokumentację VOMS aby uzyskać więcej szczegółowych informacji.

Dla każdej VO, z którą chcesz interakcjonować, odpowiednia konfiguracja musi być przygotowana. Może to być czasochłonny proces, szczególnie w przypadkach, gdy administrator serwisu nie wie z góry, które VO skonfigurować.

Aby ułatwić życie, przyjmujemy podejście oparte na danych.

Niezbędne dane są dostępne przez API Portalu Operacyjnego EGI, które jest używane w tej roli jako źródło danych. Dzięki temu możemy skonfigurować wszystkie VO zarejestrowane w Portalu Operacyjnym za jednym zamachem. Można podjąć dwa podejścia do generowania konfiguracji:

1. konfiguracja z surowych danych pobranych z Lavoisier w czasie wykonywania Ansible
2. konfiguracja z przefiltrowanych danych pobranych z Lavoisier przed czasem wykonywania Ansible.

W pierwszym podejściu można użyć odpowiednio skonstruowanego json_query do iteracji po danych zwróconych przez Lavoisier. Zapytanie w tym przypadku musi odzwierciedlać złożoność i strukturę obiektu danych zwróconego przez Lavoisier, co nie może być zakładane, że zwróci ono tablicę konsekewntnych danych. W drugim podejściu używa się znacznie prostszego rozwiązania do iteracji po danych w pamięci podręcznej, które zostały przefiltrowane, aby wykluczyć elementy, które nie zawierają istotnych informacji. Dane w pamięci podręcznej można łatwo stworzyć za pomocą prostego skryptu pythona - files/create_clean_vo_data.py, który odczytuje zmienne roli i tworzy lokalną pamięć podręczną danych. Format danych został wybrany jako YAML, abyśmy mogli dodać go do repozytorium i śledzić zmiany - byłoby to trudne z JSON, ze względu na brak linii.

Wybraliśmy drugie podejście (zobacz 4215026e18c) z następujących powodów:

1. Łatwiej jest utrzymać dobrze udokumentowany skrypt niż złożone zapytanie json.
2. Łatwiej jest czytać dobrze udokumentowany skrypt niż złożone zapytanie json.
3. Jeśli rola zostanie dodana jako zależność do playbooków (co na pewno będzie miało miejsce, ponieważ klienci VOMS są używani wszędzie), dane muszą być obecne.

Istnieje jednak wada, że dane w repozytorium mogą szybko stać się niesynchroniczne z rzeczywistymi danymi w Lavoisier. Może się to zdarzyć zarówno przez ręczne edytowanie pamięci podręcznej przez osoby, jak i przez to, że osoba utrzymująca nie uruchomiła skryptu w odpowiednim czasie. Jedynym sposobem na przezwyciężenie tego problemu jest utrzymanie silnego zestawu testów.

Aktualizacja danych VO

Aby zaktualizować dane VO przy użyciu files/create_clean_vo_data.py, wymagany jest token uwierzytelniający do interakcji z API Portalu Operacyjnego EGI.

Token można wygenerować, uzyskując dostęp do dokumentacji API Portalu Operacyjnego, będąc uwierzytelnionym przez EGI Check-in, postępując zgodnie z instrukcjami na stronie, a następnie eksportując token do środowiska przed uruchomieniem files/create_clean_vo_data.py.

Możliwe jest przetestowanie, czy token działa, za pomocą wywołania curl:

# Eksportowanie tokena API Portalu Operacyjnego
$ export OPS_PORTAL_API_TOKEN='...'
# Testowanie wywołania API za pomocą 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"

Gdy wywołanie curl zostanie potwierdzone jako działające, można użyć dostarczonego skryptu:

# Eksportowanie tokena API Portalu Operacyjnego
$ export OPS_PORTAL_API_TOKEN='...'
# Aktualizacja danych VO
$ ./files/create_clean_vo_data.py

Testowanie

Rola jest testowana za pomocą molecule dla następujących scenariuszy:

• default (testowane za pomocą TestInfra)

Testy obejmują testy jednostkowe i integracyjne, ale nie testy funkcjonalne, ponieważ do użycia klienta VOMS niezbędny jest osobisty certyfikat. W szczególności testy obejmują:

• obecność plików wykonywalnych
• obecność katalogów konfiguracyjnych
• zawartość plików konfiguracyjnych dla wybranych VO

Wymagania

Zobacz requirements.txt.

Zmienne roli

Zmienne roli przechowywane w defaults/main.yml obejmują:

• prerequisites - wymagane pakiety w zależności od systemu operacyjnego
• voms_dir, vomses_dir - lokalizacje katalogów na docelowym hoście, które zawierają informacje o voms
• lavoisier - punkty końcowe frameworka lavoisier potrzebne do pobierania danych do wypełnienia plików konfiguracyjnych.

Nie ma potrzeby zmieniania domyślnych zmiennych.

Zależności

Zależności nie są wyraźnie zadeklarowane w metadanych, ale ta rola zależy od roli UMD:

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

Przykład Playbooka

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

Licencja

Apache-2.0

Informacje o autorze

Zobacz AUTHORS.md