Integracja Single Sing-On z SSH
Ethan Heilman
OPKSSH to narzędzie oparte na protokole OpenPubkey, które umożliwia uwierzytelnianie w systemach SSH przy użyciu tokenów wydawanych przez dostawców tożsamości (Identity Providers, IdP) obsługujących standard OpenID Connect. Dzięki temu użytkownicy mogą logować się na serwery SSH, przedstawiając swój token zamiast tradycyjnego klucza SSH.
Wdrożenie OPKSSH przynosi szereg korzyści dla administratorów i użytkowników, w tym:
- Zwiększone bezpieczeństwo: OPKSSH zastępuje długotrwałe klucze SSH kluczami tymczasowymi, które wygasają po określonym czasie (domyślnie 24 godziny). To znacząco ogranicza ryzyko związane z kompromitacją kluczy i utratą dostępu.
- Lepsza wygoda użytkowania: Generowanie kluczy SSH odbywa się poprzez proste zalogowanie do dostawcy tożsamości. Użytkownicy mogą korzystać z SSH na dowolnym komputerze z zainstalowanym OPKSSH, bez konieczności przenoszenia plików kluczy prywatnych.
- Większa przejrzystość: OPKSSH przenosi autoryzację dostępu z poziomu kluczy publicznych na poziom tożsamości. Administratorzy mogą przypisywać uprawnienia dostępu na podstawie adresów e-mail użytkowników, co znacznie ułatwia śledzenie, kto ma dostęp do określonych zasobów.
Proces uwierzytelniania za pomocą OPKSSH przebiega następująco:
- Użytkownik uruchamia polecenie
opkssh logini loguje się do dostawcy tożsamości (np. Google) za pośrednictwem protokołu OpenID Connect. - OPKSSH generuje tymczasową parę kluczy (publiczny i prywatny) dla użytkownika oraz token PK (PK Token), który zawiera informacje o tożsamości użytkownika i jego kluczu publicznym.
- Token PK jest osadzany w pliku klucza publicznego SSH i przechowywany w katalogu
.sshużytkownika. - Podczas próby nawiązania połączenia SSH, klient SSH wysyła plik klucza publicznego zawierający token PK do serwera SSH.
- Serwer SSH przekazuje otrzymany plik do weryfikatora OpenPubkey, który sprawdza poprawność tokenu PK, dopasowanie klucza publicznego oraz uprawnienia użytkownika do dostępu do serwera.
- Po pomyślnej weryfikacji, użytkownik uzyskuje dostęp do serwera SSH.
Instalacja i konfiguracja OPKSSH jest relatywnie prosta. Wystarczy pobrać i zainstalować pakiet OPKSSH, a następnie wprowadzić dwie zmiany w pliku konfiguracyjnym serwera SSH (sshd_config). Cały proces jest w pełni udokumentowany w przewodniku instalacyjnym projektu.
Incydent w Cloudflare
Phillip Jones
W dniu 21 marca 2025 r. Cloudflare doświadczył zakłóceń w działaniu kilku ważnych usług, wliczając w to magazyn obiektów R2.
Główny okres zakłóceń wystąpił między 21:38 a 22:45 czasu UTC. W tym czasie doszło do całkowitego załamania operacji zapisu do magazynu R2 oraz około 35-procentowego wskaźnika niepowodzeń przy odczycie danych na poziomie globalnym. Wpływ incydentu rozciągnął się również na inne usługi Cloudflare zależne od R2, takie jak Cache Reserve, Images, Log Delivery, Stream oraz Vectorize.
Przyczyną incydentu był błąd ludzki podczas rutynowej rotacji kluczy dostępowych wykorzystywanych przez usługę R2 Gateway do uwierzytelniania wobec infrastruktury magazynującej. Nowe klucze zostały przez pomyłkę wdrożone w środowisku developerskim zamiast produkcyjnym, co skutkowało utratą autoryzacji przez działającą usługę produkcyjną po usunięciu starych kluczy.
Po zauważeniu stopniowego spadku dostępności usługi R2, zespół inżynierski podjął działania zmierzające do ustalenia przyczyn problemu. Kiedy około godziny 22:36 UTC wykryto, że nowe klucze zostały wdrożone w niewłaściwym środowisku, niezwłocznie przystąpiono do wdrożenia poprawek. O 22:45 UTC dostępność usługi została przywrócona po zakończeniu procesu rotacji kluczy w środowisku produkcyjnym.
Aby zapobiec podobnym incydentom w przyszłości, Cloudflare wprowadził szereg środków, takich jak:
- Dodanie znaczników logowania identyfikujących używane klucze dostępowe
- Obowiązkowa weryfikacja zgodności nowych kluczy przed usunięciem poprzednich
- Wdrażanie rotacji kluczy przez narzędzia do wydań hotfix zamiast poleceń ręcznych
- Aktualizacja procedur operacyjnych uwzględniająca weryfikacje przez co najmniej dwie osoby
- Rozszerzenie monitorowania punktów końcowych o testy nowych kluczy i automatyczne generowanie alertów
- Usprawnienie możliwości wykrywania problemów z magazynem poprzez udoskonaloną obserwowalność
Projektowanie sieci z OpenShift
Substack
Artykuł wprowadza w tematykę projektowania sieci w OpenShift, wyjaśniając, jak kontenery, usługi i użytkownicy komunikują się wewnątrz i na zewnątrz klastra. OpenShift rozszerza networking znany z Kubernetes, wprowadzając dodatkowe narzędzia do kontroli i widoczności.
Routing IPv6 w Wireguard
Wido den Hollander
W artykule opisano proces routingu własnego adresu IPv6 /48 do sieci domowej przy użyciu WireGuard, a także konfiguracji oraz wyzwań związanych z tym zadaniem. Autor, będąc członkiem RIPE, uzyskał przydział IPv6 /29, ale z powodu ograniczeń swojego dostawcy internetu (Ziggo Zakelijk), który przypisał mu statyczny /48, postanowił skonfigurować tunel WireGuard z serwera w Amsterdamie. Dzięki temu mógł korzystać z własnej przestrzeni adresowej IPv6 w domu bez konieczności ponownego numerowania w przypadku zmiany dostawcy.
Wskazówki dotyczących zmiany dostawcy Internetu w centrach danych
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj