Artykuł · · 3 min czytania
Jak Netflix potwierdza tożsamość zadań Spark na Amazon EMR
Zadanie Spark na Amazon EMR otrzymuje poświadczenia roli AWS IAM. Wewnętrzne usługi Netflixa rozpoznają jednak tożsamość projektu danych na podstawie krótkotrwałego certyfikatu X.509, używanego do wzajemnego TLS (mTLS). W architekturze opisanej przez Netflix usługa tożsamości wydaje taki certyfikat dopiero po sprawdzeniu roli, z którą proces naprawdę działa, i podpisanego zlecenia jego uruchomienia.
Dlaczego sama rola IAM nie wystarcza
Projekt danych w Netflixie ma własną tożsamość. To do niej przypisane są między innymi uprawnienia do tabel i zapisy audytowe. Zadanie działa jako projekt, a nie jako osoba, która je uruchomiła. AWS potrafi potwierdzić rolę IAM procesu, lecz nie zna wewnętrznego projektu ani zakresu certyfikatu, który zadanie powinno dostać.
Każdy projekt ma więc osobną rolę IAM. Usługa zarządzająca projektami przechowuje przyporządkowanie projektu do roli. Netflix nie próbuje odczytywać nazwy projektu z nazwy roli: o przypisaniu decyduje ta mapa.
Netflix spodziewa się dziesiątek tysięcy projektów. Aby zmieścić ich role w limitach AWS, rozdziela je w przewidywalny sposób między kilka kont. Przy okazji role zadań trafiają na inne konta niż usługi, które te zadania uruchamiają.
Atestacja krok po kroku
Atestacja zaczyna się przy uruchomieniu zadania, a kończy wydaniem certyfikatu sterownikowi Spark:
- Usługa uruchamiająca zadanie sprawdza, kto je zgłasza, pobiera rolę przypisaną projektowi i podpisuje metadane. Zapisuje w nich tożsamość projektu, rolę oraz zakres przyszłego certyfikatu. Podpisany pakiet przekazuje w konfiguracji zadania.
- Wtyczka w sterowniku Spark używa poświadczeń roli zadania, aby podpisać żądanie
sts:GetCallerIdentity. Powstaje krótkotrwały URL, pod którym AWS STS może potwierdzić rolę użytych poświadczeń. Sterownik przesyła ten URL i podpisane metadane do usługi tożsamości Netflixa. - Usługa tożsamości wywołuje URL w AWS STS i odczytuje rolę. Osobno sprawdza podpis metadanych, który może złożyć tylko uprawniona usługa uruchamiająca zadania.
- Usługa tożsamości porównuje wyniki. Rola potwierdzona przez STS musi być rolą wskazaną w podpisanych metadanych dla danego projektu. Dopiero wtedy usługa wystawia krótkotrwały certyfikat X.509 o zakresie określonym w tych metadanych.
Oba dowody są potrzebne. Odpowiedź STS mówi, jakiej roli użył proces, ale nic o projekcie danych. Podpisane metadane podają projekt i potwierdzają, że zadanie zleciła uprawniona usługa, lecz można je skopiować; same nie dowodzą posiadania poświadczeń roli. Krótkotrwały URL też jest przenośny, dlatego usługa tożsamości nie przyjmuje go jako pełnego opisu zadania.
Jak certyfikat trafia do wykonawców
Jedno zadanie Spark może mieć tysiące procesów wykonawczych. Gdyby każdy z nich przechodził atestację, pojedyncze zadanie mogłoby wywołać tysiące żądań do STS i usługi tożsamości. Netflix atestuje więc sterownik raz, a ten przekazuje poświadczenia wykonawcom przez wewnętrzny protokół RPC Sparka. Połączenia są uwierzytelniane i szyfrowane przy użyciu AES-GCM.
Sterownik ponawia atestację przed wygaśnięciem certyfikatu. Wykonawcy nie odnawiają swoich certyfikatów. Gdy któryś działa dłużej niż ważność poświadczeń, może zakończyć pracę i zostać zastąpiony.
Ten wybór czyni sterownik punktem dystrybucji poświadczeń dla całego zadania. Przejęcie sterownika zagraża więc tożsamości jego wykonawców. Wykonawcy nie potwierdzają osobno swojej roli w STS. Rozwiązanie opisuje sposób działania Netflixa na Spark i EMR; przeniesienie go do innego środowiska wymagałoby własnego sposobu uruchamiania zadań, poświadczania roli i bezpiecznego przekazywania certyfikatów.
Źródła
- Dhruv Pratap, Netflix Technology Blog, „Trading a Cloud Identity for Your Own: Workload Attestation on Managed Compute”, 2026.