Zdefiniuj operację VPN, zanim porównasz API

Strona produktu twierdzi, że ma API, a spotkanie integracyjne grzęźnie na drugim pytaniu. Jaka operacja, na jakim obiekcie, wywoływana przez kogo i co liczy się jako sukces? Odpowiedź na te cztery pytania przed porównaniem produktów zwykle eliminuje połowę kandydatów. Zamienia też pozostałe porównanie w coś, co rozstrzygnie test.

Zastąp „ma API” jedną operacją

API to transport, nie zdolność. Punkt końcowy REST, gniazdo lokalne i nakładka na wiersz poleceń mogą wszystkie nazywać się API, a nie oferują równoważnych operacji.

Zapisz operację jako zdanie, zanim zajrzysz do dokumentacji.

Rozpoczęcie lokalnego połączenia to działanie po stronie klienta z użytkownikiem przed nim. Wydanie profilu urządzenia to działanie zaopatrzeniowe z inwentarzem w tle. Wyłączenie dostępu użytkownika to działanie administracyjne ze śladem audytu. Te trzy zwykle mieszkają w różnych komponentach, należą do różnych zespołów i mają różne uprawnienia.

Cztery pola, które czynią kontrakt testowalnym

Wypełnij cztery pola dla każdej operacji: obiekt, działanie, wywołującego i warunek sukcesu. Kontrakt z brakującym polem to życzenie.

Tabela to cały arkusz roboczy:

Warunek sukcesu to pole, które ludzie pomijają, a właśnie ono decyduje, czy integracja działa. Zapisane ustawienie to nie aktywny tunel, a wyłączone konto to nie zakończona sesja.

Jeśli dwie operacje potrzebują różnych wywołujących, to dwie integracje. Połączenie ich w jedno konto usługi zwykle oznacza przyznanie większych uprawnień, niż potrzebuje którakolwiek z nich.

Dopasuj interfejs do warstwy, do której naprawdę należy

Wspólnotowy interfejs zarządzania OpenVPN rozmawia z demonem przez TCP lub gniazdo Unix. Jego polecenia obejmują obserwację stanu i sygnały do demona.

To czyni go kanałem sterowania demonem, a nie hostowanym API subskrypcji ani usługą rejestracji użytkowników. Uważne czytanie jego dokumentacji oszczędza budowania na warstwie, która nie jest właścicielem obiektu.

Ta dokumentacja mówi też, że protokół nie ma własnego szyfrowania. Kto może dosięgnąć gniazda, ten może sterować demonem, więc traktuj je jako wrażliwe sterowanie, a nie strumień metryk. Przypisz je do loopbacku lub gniazda Unix i umieść za ograniczonym rozwiązaniem, jeśli zdalny wywołujący go potrzebuje. Wystawienie go do internetu dla wygody zamienia kanał sterowania w incydent.

Określ zachowanie po wywołaniu

Akceptacja to nie to samo co zakończenie. Demon może odpowiedzieć, zanim tunel wstanie, więc czekaj na udokumentowane zdarzenie zakończenia lub błędu i powiąż je z wysłanym żądaniem.

Zdecyduj, co robi wywołujący, jeśli odpowiedź zginie. Ślepe powtarzanie utworzenia lub ponownego połączenia to nie to samo co sprawdzenie, czy pierwsze żądanie już zadziałało.

Odebranie dostępu to co najmniej trzy różne działania: zablokowanie przyszłego logowania, zakończenie aktywnej sesji i unieważnienie poświadczenia. Proś o te, których naprawdę wymaga polityka, i wskaż w kontrakcie, które jest które. Nie nazywaj jednej udanej aktualizacji konta pełnym unieważnieniem bez dowodu. Ta różnica ma znaczenie podczas incydentu, gdy zegar tyka.

Sprawdź kontrakt pilotażem

Mały zatwierdzony pilotaż powinien obejmować sukces, odrzucenie, przerwanie i ponowną próbę, a następnie operację aplikacji, która ma być dozwolona lub odrzucona.

Dla interfejsu na poziomie demona dwa polecenia ćwiczą obserwację i sygnał:

echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505

Przyznaj tylko uprawnienie wymagane przez operację. Trzymaj sekrety z dala od rutynowych logów i zapisuj dość prywatnych szczegółów, by powiedzieć, który cel został dotknięty i jak się to skończyło.

Zapisz ścieżkę odzyskiwania na wypadek, gdy samo API sterowania jest niedostępne. Wybierz interfejs, który jest właścicielem obiektu i jego cyklu życia; deklaracje automatyzacji na stronie produktu nie są zamiennikiem.