Tożsamość zadania Spark wymaga potwierdzenia roli i uruchomienia
Zadanie Spark uruchomione w zarządzanej usłudze Amazon EMR dostaje poświadczenia roli IAM. Wewnętrzne usługi firmy mogą jednak wymagać innej tożsamości: przypisanej do projektu danych, używanej do kontroli dostępu do tabel i zapisów audytowych. Sama rola chmurowa nie mówi jeszcze, które zadanie powinno otrzymać taki dostęp.
Jedna rola IAM odpowiada jednemu projektowi danych
W opisanym przez Netflix rozwiązaniu dla Spark na EMR każdy projekt danych ma własną rolę IAM. Usługa zarządzająca projektami przechowuje przyporządkowanie jeden do jednego. To ono pozwala przełożyć rolę przydzieloną przez AWS na wewnętrzną tożsamość projektu. Bez autorytatywnej mapy poprawnie rozpoznana rola nadal nie wskazywałaby, dla którego projektu wystawić certyfikat.
Netflix spodziewa się dziesiątek tysięcy projektów, więc rozdziela ich role deterministycznie między kilka kont AWS. Ma to ominąć limit liczby ról na pojedynczym koncie i oddzielić role zadań od kont używanych przez usługi uruchamiające zadania. Ten układ zależy od utrzymania mapy rola–projekt; nie wystarczy wyprowadzać nazwy projektu z nazwy roli.
Certyfikat wymaga zgodności dwóch deklaracji
Jedyna usługa uprawniona do uruchamiania zadań sprawdza zgłaszającego, wybiera rolę projektu i podpisuje metadane z tożsamością zadania oraz zakresem przyszłego certyfikatu. Przekazuje podpisany pakiet jako konfigurację zadania. Podpis potwierdza, że autoryzowana usługa zleciła uruchomienie, ale sam pakiet można skopiować i odtworzyć.
Wtyczka inicjalizowana w procesie sterownika Spark używa otrzymanych poświadczeń IAM do podpisania żądania sts:GetCallerIdentity. Nie wysyła go bezpośrednio. Przekazuje do wewnętrznej usługi tożsamości krótkotrwały, podpisany URL oraz metadane z podpisem usługi uruchamiającej. Usługa tożsamości wywołuje ten URL w AWS STS, odczytuje rolę, weryfikuje drugi podpis i sprawdza, czy obie deklaracje wskazują tę samą rolę przypisaną wskazanemu projektowi. Dopiero wtedy wystawia krótkotrwały certyfikat X.509 używany do wzajemnego TLS.
STS potwierdza rolę użytych poświadczeń, lecz nie zna wewnętrznej nazwy projektu ani celu uruchomienia. Podpisana konfiguracja podaje te informacje, ale bez odpowiedzi STS nie dowodzi, że zgłaszający posiada poświadczenia właściwej roli. Krótkotrwały URL jest przy tym przenośny: kto go przejmie w okresie ważności, może go wywołać. Opis Netflixa pokazuje wzajemną kontrolę obu deklaracji, a nie kryptograficzne przypisanie certyfikatu do każdego procesu wykonawczego z osobna.
Sterownik przekazuje certyfikaty wykonawcom
Jedno zadanie Spark może uruchomić tysiące procesów wykonawczych. Gdyby każdy z nich osobno powtarzał atestację, pojedyncze zadanie wywołałoby tysiące żądań do STS i usługi tożsamości. Netflix wybrał atestację sterownika i przekazywanie poświadczeń wykonawcom przez wewnętrzne RPC Spark, zabezpieczone uwierzytelnieniem i szyfrowaniem AES-GCM. Zmniejsza to liczbę żądań atestacyjnych, ale czyni sterownik punktem dystrybucji certyfikatów. To uprawnienie trzeba uwzględnić przy ocenie granicy zaufania między sterownikiem a wykonawcami.
Certyfikaty wygasają podczas długich zadań. Sterownik ponawia atestację przed upływem ich ważności i odnawia poświadczenia; krócej żyjący wykonawca, którego certyfikat wygaśnie, może zakończyć pracę i zostać zastąpiony. Opis dotyczy architektury Netflixa na Spark i EMR. Nie podaje pomiaru skuteczności wobec przejęcia sterownika ani gwarancji, że taka sama wymiana tożsamości zadziała bez zmian w innym środowisku uruchomieniowym.
Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.