Role IAM dla kont usług (IRSA)

Gdy pod uruchomiony w EKS musi wywołać interfejs API AWS — na przykład odczytać dane z S3 lub zapisać je w DynamoDB — potrzebuje poświadczeń AWS. Naiwnym podejściem jest utworzenie użytkownika IAM i zapisanie jego kluczy dostępu na stałe w zmiennych środowiskowych. Jest to niebezpieczne i narusza zasadę najmniejszych uprawnień, ponieważ wszystkie pody na tym samym węźle współdzielą poświadczenia. IAM Roles for Service Accounts (IRSA) rozwiązuje ten problem, przypisując precyzyjnie określone role IAM bezpośrednio do kont usług Kubernetes.

IRSA działa za pośrednictwem federacji OpenID Connect (OIDC). EKS tworzy dostawcę OIDC dla klastra. Gdy pod odwołuje się do konta usługi z adnotacją zawierającą ARN roli IAM, EKS wstrzykuje do poda podpisany projekcyjny token konta usługi. AWS SDK działający w podzie wymienia ten token na tymczasowe poświadczenia AWS za pomocą interfejsu API AWS STS AssumeRoleWithWebIdentity — nie są potrzebne klucze długoterminowe.

Przed użyciem IRSA należy powiązać wystawcę OIDC EKS jako zaufanego dostawcę tożsamości na koncie AWS. Spowoduje to utworzenie zasobu dostawcy OIDC IAM, który zostanie rozpoznany przez AWS STS. Polecenie eksctl obsługuje to automatycznie. Po utworzeniu zasobu można zweryfikować go w konsoli IAM w sekcji Identity Providers.

Rola IAM używana przez IRSA musi zawierać politykę zaufania, która zezwala dostawcy OIDC na przyjęcie tej roli, ograniczając to uprawnienie do określonej przestrzeni nazw Kubernetes i konta usługi. Warunek używa deklaracji sub w tokenie OIDC, której wartość ma postać system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Gwarantuje to, że rolę mogą przyjąć tylko pody korzystające z tego konkretnego konta usługi — a nie dowolny pod w klastrze.

Należy utworzyć obiekt Kubernetes ServiceAccount w docelowej przestrzeni nazw i dodać do niego adnotację z ARN roli IAM. Gdy pod odwołuje się do tego konta usługi, EKS automatycznie wstrzykuje token OIDC oraz dwie zmienne środowiskowe (AWS_WEB_IDENTITY_TOKEN_FILE i AWS_ROLE_ARN). AWS SDK automatycznie je wykrywa i wywołuje STS w celu uzyskania tymczasowych poświadczeń — aplikacja nie wymaga żadnych zmian w kodzie.

W specyfikacji poda lub wdrożenia należy ustawić serviceAccountName na nazwę konta usługi z adnotacją. Podczas planowania poda przez EKS token OIDC jest automatycznie montowany pod adresem /var/run/secrets/eks.amazonaws.com/serviceaccount/token, a wymagane zmienne środowiskowe są ustawiane. Każde wywołanie AWS SDK wewnątrz poda będzie w sposób transparentny korzystać z poświadczeń przypisanej roli IAM, bez jawnego konfigurowania poświadczeń.

W przypadku roli IAM węzła każdy pod na węźle dziedziczy te same uprawnienia — przejęty pod może uzyskać dostęp do wszystkich usług AWS, do których węzeł ma dostęp. W przypadku IRSA każdy pod (za pośrednictwem swojego konta usługi) przyjmuje tylko rolę, której potrzebuje. Jest to zgodne z zasadą najmniejszych uprawnień na poziomie poda i ogranicza zakres potencjalnych skutków incydentu bezpieczeństwa. AWS zaleca używanie IRSA zamiast ról na poziomie węzłów we wszystkich nowych wdrożeniach EKS.

eksctl może utworzyć powiązanie OIDC, rolę IAM, politykę zaufania i adnotację Kubernetes ServiceAccount za pomocą jednego polecenia create iamserviceaccount. Jest to najprostszy sposób skonfigurowania IRSA bez ręcznego tworzenia kodu JSON polityki zaufania. Należy podać przestrzeń nazw, nazwę konta usługi oraz ARN polityki IAM, która ma zostać dołączona, a eksctl zajmie się resztą.

Wiele dodatków i kontrolerów EKS wymaga IRSA do działania: Cluster Autoscaler potrzebuje uprawnień do wywoływania interfejsu API EC2 Auto Scaling, AWS Load Balancer Controller potrzebuje uprawnień do tworzenia zasobów ELB i zarządzania nimi, external-dns potrzebuje dostępu do zapisu w Route 53, a EBS CSI driver potrzebuje uprawnień do tworzenia woluminów EBS i dołączania ich. Dla tych komponentów systemowych zawsze należy używać IRSA — nigdy nie należy nadawać tych uprawnień na poziomie roli IAM węzła.

Tokeny IRSA są krótkotrwałe i automatycznie rotowane przez kontroler projekcji tokenów Kubernetes przed wygaśnięciem. Domyślna grupa odbiorców tokenu to sts.amazonaws.com, a jego czas wygaśnięcia wynosi 24 godziny, jednak kontroler odświeża tokeny po upływie 80% ich czasu życia. Poświadczenia AWS STS uzyskane za pośrednictwem IRSA są również tymczasowe (zwykle ważne przez 1 godzinę). Automatyczna rotacja eliminuje obciążenie związane z rotacją poświadczeń, które występuje w przypadku długoterminowych kluczy dostępu IAM.

Za każdym razem, gdy pod przyjmuje rolę IAM za pośrednictwem IRSA, AWS CloudTrail rejestruje zdarzenie AssumeRoleWithWebIdentity. Zdarzenie zawiera ARN przyjętej roli, podmiot tokenu OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) oraz źródłowy adres IP. Zapewnia to pełny ślad audytowy pokazujący, które pody uzyskiwały dostęp do których usług AWS i kiedy — co ma kluczowe znaczenie w procesach zgodności oraz podczas badania incydentów w regulowanych środowiskach.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omawianych w tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: IRSA używa federacji OIDC do wymiany tokenów kont usług Kubernetes na tymczasowe poświadczenia AWS, polityki zaufania ról IAM ograniczają dostęp do określonej przestrzeni nazw i konta usługi, a IRSA zapewnia najmniejsze uprawnienia dla każdego poda, znacznie przewyższając pod tym względem role IAM na poziomie węzła. W następnej części omówimy metryki, przestrzenie nazw i wymiary CloudWatch służące do monitorowania zasobów AWS.