Zagłębianie się w role uprawnień IAM dla Service Accounts

Popularnym wyzwaniem przed jakim stają architekci podczas projektowania rozwiązania Kubernetes w AWS, jest przyznawanie uprawnień dla kontenerów w celu uzyskania dostępu do usługi lub zasobu AWS. AWS Identity and Access Management (IAM) zapewnia szczegółową kontrolę dostępu, w której można określić, kto może uzyskać dostęp do której usługi lub zasobów AWS, zapewniając zasadę minimalnych uprawnień. Jednak, gdy Twój workload jest uruchomiony w Kubernetesie, zapewnienie mu tożsamości, której może używać IAM do uwierzytelniania, staje się wyzwaniem.

W 2019 AWS uruchomił usługę IAM Roles for Service Accounts (IRSA), wykorzystując interfejsy API tożsamości AWS, dostawcę tożsamości OpenID Connect (OIDC) i Service Accounts Kubernetes w celu zastosowania szczegółowej kontroli dostępu dla podów Kubernetes. Aby uzyskać więcej informacji, zapoznaj się z wpisem przedstawiającym IRSA.

W tym poście planujemy zagłębić się w temat IRSA, pomagając Ci zrozumieć, jak różne elementy łączą się ze sobą i co naprawdę dzieje się za kulisami.

Przewodnik

W tym przewodniku pokażemy koncepcje, w jaki sposób można wykorzystać konta usługi (service accounts) Kubernetes w celu uzyskania dostępu do usługi i zasobu AWS. Uruchomimy wiele podów Kubernetes w klastrze Amazon EKS, próbując uzyskać dostęp do Amazon S3.

Wymagania wstępne:

• Aktywne konto Amazon Web Services (AWS).
• Interfejs AWS Command Line Interface (AWS CLI) w wersji 2 lub nowszej, zainstalowany i skonfigurowany w systemie macOS, Linux lub Windows, z odpowiednimi uprawnieniami IAM do tworzenia klastra EKS i tworzenia ról IAM.
• Narzędzie wiersza poleceń kubectl, zainstalowane i skonfigurowane do uzyskiwania dostępu do klastra Amazon EKS. Aby uzyskać więcej informacji na ten temat, zobacz Instalowanie kubectl w dokumentacji Amazon EKS.
• Narzędzie wiersza poleceń eksctl (wersja >= 0.5.0). Więcej informacji na temat instalacji można znaleźć w tej dokumentacji.
• Narzędzie wiersza poleceń jq do analizowania składni json.
• Narzędzie jwt-cli do dekodowania tokenów internetowych JSON.

Szczegóły krok po kroku

Zacznijmy od stworzenia klastra EKS.

$ eksctl create cluster \

--name eks-oidc-demo \

--region us-east-2

Następnie utworzymy pojedynczy pod Kubernetes z zasadą ponownego uruchamiania, aby nie podejmować prób ponownego uruchomienia poda po zakończeniu workloadu wewnątrz poda. Kubernetes Pod wykorzystuje obraz kontenera amazon/aws-cli i wykonuje polecenie  aws s3 list  wewnątrz poda.

$ cat <<EOF | kubectl apply -f -

apiVersion: v1

kind: Pod

metadata:

  name: eks-iam-test1

spec:

  containers:

    - name: my-aws-cli

      image: amazon/aws-cli:latest

      args: ['s3', 'ls']

  restartPolicy: Never

EOF

Używając polecenia kubectl get pod, możemy zobaczyć, że pod został uruchomiony. Jednak zakończył pracę z błędem.

$ kubectl get pod

NAME              READY   STATUS   RESTARTS   AGE

eks-iam-test1     0/1     Error    0          37s

Patrząc na logi, możemy zobaczyć podstawową przyczynę. Podczas wywoływania listowania bucketów, otrzymujemy błędy odmowy dostępu (jest to oczekiwane na tym etapie).

$ kubectl logs eks-iam-test1

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

Sprawdzając konsolę AWS CloudTrail w konsoli AWS Management Console, możemy uzyskać dodatkowe szczegóły dotyczące tego błędu. Ponieważ próbujemy wyświetlić listę bucketów, możemy filtrować zdarzenia CloudTrail, ustawiając nazwę zdarzenia na „List Buckets”.

Wybierz zdarzenie ListBuckets w logach CloudTrail, otwórz logi zdarzeń, a zobaczysz wynik podobny do następującego:

{

...

  "userIdentity": {

    "type": "AssumedRole",

    "principalId": "xxxx",

    "arn": "arn:aws:sts::111122223333:assumed-role/eksctl-eks-oidc-demo-nodegroup-ng-NodeInstanceRole-xxxx/xxxx",

    "accountId": "111122223333",

    "accessKeyId": "AKIAIOSFODNN7EXAMPLE",

    "sessionContext": {

      "sessionIssuer": {

        "type": "Role",

        "principalId": "xxxx",

        "arn": "arn:aws:iam::xxxx:role/eksctl-eks-oidc-demo-nodegroup-ng-NodeInstanceRole-xxxx",

        "accountId": "111122223333",

        "userName": "eksctl-eks-oidc-demo-nodegroup-ng-NodeInstanceRole-xxxx"

      },

      "webIdFederationData": {},

      "attributes": {

        "creationDate": "2021-12-04T14:54:49Z",

        "mfaAuthenticated": "false"

      },

      "ec2RoleDelivery": "2.0"

    }

  },

  "eventTime": "2021-12-04T15:09:20Z",

  "eventSource": "s3.amazonaws.com",

  "eventName": "ListBuckets",

  "awsRegion": "us-east-2",

  "sourceIPAddress": "192.0.2.1",

  "userAgent": "[aws-cli/2.4.5 Python/3.8.8 Linux/5.4.156-83.273.amzn2.x86_64 docker/x86_64.amzn.2 prompt/off command/s3.ls]",

  "errorCode": "AccessDenied",

  "errorMessage": "Access Denied",

  "requestParameters": {

    "Host": "s3.us-east-2.amazonaws.com"

  },

...

}

W sekcji danych wyjściowych userIdentity widać, że nasz workload działający w Kubernetes Pod przyjmuje rolę IAM połączoną z instancją Amazon EC2 i wykorzystuje tę rolę, aby spróbować wyświetlić listę bucketów S3. Dzieje się tak, ponieważ w kontenerze nie znaleziono żadnych innych poświadczeń AWS, więc zestaw SDK powrócił do serwera metadanych IAM, jak wspomniano w dokumentacji python boto3 sdk.

Ponieważ rola uprawnień IAM w profilu instancji EC2 nie ma niezbędnych uprawnień do wyświetlania listy bucketów, polecenie otrzymało błąd „Access Denied”. Jednym ze sposobów rozwiązania tego problemu może być dołączenie dodatkowych uprawnień do profilu instancji EC2. Jednak narusza to kluczową zasadę bezpieczeństwa, zasadę minimalnych uprawnień. To dodatkowe uprawnienie byłoby na poziomie węzła EC2, a nie na poziomie podu Kubernetesa. Dlatego wszystkie pody działające w tym węźle uzyskają dostęp do naszych bucketów S3. Chcemy ograniczyć to uprawnienie do poziomu poda.

To prowadzi nas do kolejnego pytania: jak możemy dodać poświadczenia AWS do kontenera, aby kontener nie był domyślnie ustawiany na profil instancji EC2? Dodawanie poświadczeń AWS za pośrednictwem Kubernetes Secrets lub zmiennych środowiskowych nie byłoby bezpieczne, a użytkownik musiałby zarządzać cyklem życia tych poświadczeń. Nie polecamy żadnego z tych podejść.

Kubernetes Service Accounts

Pody Kubernetes otrzymują tożsamość dzięki koncepcji Kubernetes zwanej Kubernetes Service Account. Po utworzeniu konta usługi, token JWT jest automatycznie tworzony jako tzw. sekret Kubernetes. Ten sekret może być następnie zamontowany w podach i używany przez Service Account do uwierzytelniania na serwerze API Kubernetes.

$ kubectl get sa

NAME          SECRETS   AGE

default       1         23h

 

$ kubectl describe sa default

Name:                default

Namespace:           default

Labels:              <none>

Annotations:         <none>

Image pull secrets:  <none>

Mountable secrets:   default-token-8j54j

Tokens:              default-token-8j54j

Events:              <none>

Niestety ten domyślny token ma kilka problemów, które sprawiają, że nie nadaje się do uwierzytelniania uprawnień IAM. Po pierwsze, tylko serwer API Kubernetes może zweryfikować ten token. Po drugie, te tokeny konta usługi nie wygasają, a wymienianie klucza logowania jest trudnym procesem. Możesz wyświetlić token, pobierając sekret i przesyłając go przez jwt-cli.

$ kubectl get secret default-token-m4tdn -o json | jq -r '.data.token' | base64 -d | jwt decode --json -

{

  "header": {

    "alg": "RS256",

    "kid": "LflWmdoop8Xt5sUnBFTmCLX0B8MnS1kcPSUcyjr8npw"

  },

  "payload": {

    "iss": "kubernetes/serviceaccount",

    "kubernetes.io/serviceaccount/namespace": "default",

    "kubernetes.io/serviceaccount/secret.name": "default-token-m4tdn",

    "kubernetes.io/serviceaccount/service-account.name": "default",

    "kubernetes.io/serviceaccount/service-account.uid": "5af7481a-2c9c-4613-9266-1037a23961a4",

    "sub": "system:serviceaccount:default:default"

  }

}

W Kubernetes 1.12 została wprowadzona funkcja ProjectedServiceAccountToken. Funkcja ta umożliwia w pełni zgodnemu tokenowi JWT OIDC wystawionemu przez TokenRequest API Kubernetesa do zamontowania w podzie jako Projected Volume. Odpowiednie flagi Service Account Token Volume Projection są domyślnie włączone w klastrze EKS. W związku z tym w każdym podzie są rzutowane w pełni zgodne tokeny konta usługi JWT OIDC zamiast tokenu JWT wymienionego w poprzednim akapicie.

Aby sprawdzić token OIDC, możemy utworzyć nowy pod, który ma wewnątrz proces uśpienia za pomocą następującego polecenia:

$ cat <<EOF | kubectl apply -f -

apiVersion: v1

kind: Pod

metadata:

  name: eks-iam-test2

spec:

  containers:

    - name: my-aws-cli

      image: amazon/aws-cli:latest

      command: ['sleep', '36000']

  restartPolicy: Never

EOF

Ponieważ nie określiliśmy konkretnego konta usługi Kubernetes, używane jest domyślne konto usługi, a następnie generowany jest token OIDC dla konta usługi i montowany w podzie.

Token można pobrać i rozwinąć, aby pokazać w pełni zgodny token OIDC.

$ SA_TOKEN=$(kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)

$ jwt decode $TOKEN --json --iso8601

{

  "header": {

    "alg": "RS256",

    "kid": "689de1734321bcfdfbef825503a5ead235981e7a"

  },

  "payload": {

    "aud": [

      "https://kubernetes.default.svc"

    ],

    "exp": "2023-02-18T16:37:58+00:00",

    "iat": "2022-02-18T16:37:58+00:00",

    "iss": "https://oidc.eks.eu-west-1.amazonaws.com/id/xxxx",

    "kubernetes.io": {

      "namespace": "default",

      "pod": {

        "name": "eks-iam-test2",

        "uid": "cd953361-41a2-4de0-b799-51f169920741"

      },

      "serviceaccount": {

        "name": "default",

        "uid": "5af7481a-2c9c-4613-9266-1037a23961a4"

      },

      "warnafter": 1645205885

    },

    "nbf": "2022-02-18T16:37:58+00:00",

    "sub": "system:serviceaccount:default:default"

  }

}

Jak widać w payload’zie tego tokena JWT, wystawcą jest OIDC Provider. Odbiorcami tokenu są https://kubernetes.default.svc. Jest to adres wewnątrz klastra używany do łączenia się z serwerem API Kubernetes.

Ze względów bezpieczeństwa możesz nie chcieć dołączać żadnego tokena do Kubernetes Pod, jeśli workload w podzie nie będzie wywoływać serwera API Kubernetes. Można to zrobić, przekazując automountServiceAccountToken: false do specyfikacji poda podczas jego tworzenia.

Zgodny token OIDC daje nam teraz podstawę, aby znaleźć token, którego można użyć do uwierzytelniania w interfejsach API AWS. Potrzebujemy jednak dodatkowego komponentu, aby dodać drugi token do użycia z API AWS w naszych podach Kubernetesa. Kubernetes obsługuje weryfikację i mutating webhooks, a usługa AWS utworzyła webhook tożsamości, który jest preinstalowany w klastrze EKS. Element webhook nasłuchuje wywołania API create pod i może dodać dodatkowy token do naszych podów. Element webhook można również zainstalować w samodzielnie zarządzanych klastrach Kubernetes w AWS, korzystając z przewodnika.

Aby webhook mógł dodać nowy token do naszego poda, utworzymy nowe Kubernetes Service Account, dodamy do naszego konta usługi adnotację z rolą AWS IAM ARN, a następnie odwołamy się do tego nowego Kubernetes Service Account w podzie Kubernetes. Narzędzie eksctl można wykorzystać do zautomatyzowania kilku kroków za nas, ale wszystkie te kroki można również wykonać ręcznie.

Polecenie eksctl create iamserviceaccount tworzy:

• Konto Usługi Kubernetes
• Rolę IAM ze określoną polityką IAM
• Politykę zaufania do tej roli IAM

Na koniec doda również adnotację do konta usługi Kubernetes z utworzoną rolą uprawnień IAM ARN:

$ eksctl create iamserviceaccount \

  --name my-sa \

  --namespace default \

  --cluster eks-oidc-demo \

  --approve \

  --attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)

Sprawdzając nowo utworzone konto usługi Kubernetes, możemy zobaczyć, jaką rolę ma przyjąć w naszym podzie.

$ kubectl describe sa my-sa

Name: my-sa

Namespace: default

Labels: app.kubernetes.io/managed-by=eksctl

Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::xxxx:role/eksctl-eks-oidc-demo-addon-iamserviceaccount-Role1-H47XCR6FPRGQ

Image pull secrets: <none>

Mountable secrets: my-sa-token-kv6kc

Tokens: my-sa-token-kv6kc

Events: <none>

Zobaczmy, jak rola uprawnień IAM wygląda w konsoli AWS Management Console. Przejdź do IAM, a następnie IAM Roles i wyszukaj rolę. Podczas opisu konta usługi zobaczysz pole Annotations.

Widać, że do tej roli została zastosowana nasza polityka AmazonS3ReadOnlyAccess.

Wybierz kartę Trust relationships i wybierz opcję Edit trust relationship, aby wyświetlić dokument polityki.

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-2.amazonaws.com/id/xxxx"

      },

      "Action": "sts:AssumeRoleWithWebIdentity",

      "Condition": {

        "StringEquals": {

          "oidc.eks.us-east-2.amazonaws.com/id/xxxx:aud": "sts.amazonaws.com",

          "oidc.eks.us-east-2.amazonaws.com/id/xxxx:sub": "system:serviceaccount:default:my-sa"

        }

      }

    }

  ]

}

Widać, że ta zasada zezwala tożsamości system:serviceaccount:default:my-sa na przejęcie roli przy użyciu akcji sts:AssumeRoleWithWebIdentity. Podmiotem tej polityki jest dostawca OIDC.

Zobaczmy teraz, co się stanie, gdy użyjemy tego nowego konta usługi w podzie Kubernetes.

$ cat <<EOF | kubectl apply -f -

apiVersion: v1

kind: Pod

metadata:

  name: eks-iam-test3

spec:

  serviceAccountName: my-sa

  containers:

    - name: my-aws-cli

      image: amazon/aws-cli:latest

      command: ['sleep', '36000']

  restartPolicy: Never

EOF

Jeśli sprawdzimy Pod za pomocą Kubectl i JQ, zobaczymy, że są teraz dwa woluminy zamontowane w naszym podzie. Drugi został zamontowany za pomocą tego mutującego webhooka. Token aws-iam-token jest nadal generowany przez serwer API Kubernetes, ale z nową grupą odbiorców JWT OIDC.

$ kubectl get pod eks-iam-test3 -o json | jq -r '.spec.containers | .[].volumeMounts'

[

  {

    "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",

    "name": "kube-api-access-p2dlk",

    "readOnly": true

  },

  {

    "mountPath": "/var/run/secrets/eks.amazonaws.com/serviceaccount",

    "name": "aws-iam-token",

    "readOnly": true

  }

]

 

$ kubectl get pod eks-iam-test3 -o json | jq -r '.spec.volumes[] | select(.name=="aws-iam-t

oken")'

{

  "name": "aws-iam-token",

  "projected": {

    "defaultMode": 420,

    "sources": [

      {

        "serviceAccountToken": {

          "audience": "sts.amazonaws.com",

          "expirationSeconds": 86400,

          "path": "token"

        }

      }

    ]

  }

}

Jeśli uruchomimy działający Pod i sprawdzimy ten token, zobaczymy, że wygląda on nieco inaczej niż poprzedni token SA.

$ IAM_TOKEN=$(kubectl exec -it eks-iam-test3 -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token)

$ jwt decode $IAM_TOKEN --json --iso8601

{

  "header": {

    "alg": "RS256",

    "kid": "689de1734321bcfdfbef825503a5ead235981e7a"

  },

  "payload": {

    "aud": [

      "sts.amazonaws.com"

    ],

    "exp": "2022-02-19T16:43:55+00:00",

    "iat": "2022-02-18T16:43:55+00:00",

    "iss": "https://oidc.eks.eu-west-1.amazonaws.com/id/xxxx",

    "kubernetes.io": {

      "namespace": "default",

      "pod": {

        "name": "eks-iam-test3",

        "uid": "6fd2f65f-4554-4317-9343-c8e5d28029c3"

      },

      "serviceaccount": {

        "name": "my-sa",

        "uid": "2c935d89-3ff0-425d-85c2-8236a6d626aa"

      }

    },

    "nbf": "2022-02-18T16:43:55+00:00",

    "sub": "system:serviceaccount:default:my-sa"

  }

}

Widać, że zamierzonym odbiorcą dla tego tokena jest teraz sts.amazonaws.com, wystawca, który utworzył i podpisał ten token, nadal jest naszym dostawcą OIDC, a wreszcie wygaśnięcie tokena jest znacznie krótsze, po 24 godzinach. Możemy zmienić czas wygaśnięcia konta usługi, korzystając z adnotacji eks.amazonaws.com/token-expiration w naszej definicji poda lub definicji konta usługi.

Mutujący webhook nie tylko montuje dodatkowy token w podzie, ale dodaje również zmienne środowiskowe.

$ kubectl get pod aws-custom-sa-pod -o json | jq -r '.spec.containers | .[].env'

[

  {

    "name": "AWS_DEFAULT_REGION",

    "value": "us-east-2"

  },

  {

    "name": "AWS_REGION",

    "value": "us-east-2"

  },

  {

    "name": "AWS_ROLE_ARN",

    "value": "arn:aws:iam::111122223333:role/eksctl-eks-oidc-demo-addon-iamserviceaccount-Role1-1SJZ3F7H39X72"

  },

  {

    "name": "AWS_WEB_IDENTITY_TOKEN_FILE",

    "value": "/var/run/secrets/eks.amazonaws.com/serviceaccount/token"

  }

]

Te zmienne środowiskowe są używane przez AWS SDK i CLI podczas przejmowania roli z tożsamości sieci Web. Na przykład zobacz python boto3 sdk. SDK w naszym workloadzie będzie teraz używać tych poświadczeń zamiast poświadczeń znalezionych w profilu instancji EC2.

Domyślnie mutujący element webhook nie nakazuje zestawom SDK używania regionalnego punktu końcowego STS. Zamiast tego domyślnie używają starszego globalnego punktu końcowego. AWS zaleca dodanie adnotacji eks.amazonaws.com/sts-regional-endpoints: "true" do konta usługi Kubernetes. Spowoduje to dodanie zmiennej środowiskowej AWS_STS_REGIONAL_ENDPOINTS=regional do Twoich workloadów. Więcej informacji można znaleźć w dokumentacji. To zachowanie stanie się domyślne w przyszłej wersji platformy EKS.

Teraz, gdy nasz workload ma token, którego może użyć do próby uwierzytelnienia za pomocą uprawnień IAM, następną częścią jest sprawienie, aby usługa AWS IAM ufała tym tokenom. AWS IAM obsługuje tożsamości federacyjne przy użyciu dostawców tożsamości OIDC. Ta funkcja umożliwia IAM uwierzytelnianie wywołań interfejsu API AWS u obsługiwanych dostawców tożsamości po otrzymaniu prawidłowego znacznika JWT OIDC. Ten token można następnie przekazać do operacji API AWS STS AssumeRoleWithWebIdentity w celu uzyskania tymczasowych poświadczeń uprawnień IAM.

Token JWT OIDC, który mamy w naszym workloadzie Kubernetes, jest podpisany kryptograficznie, a IAM powinien ufać i weryfikować te tokeny, zanim operacja API AWS STS AssumeRoleWithWebIdentity będzie mogła wysłać tymczasowe poświadczenia. W ramach funkcji Service Account Issuer Discovery Kubernetesa, EKS obsługuje publiczny dokument konfiguracyjny dostawcy OpenID (punkt końcowy Discovery) i klucze publiczne do weryfikacji podpisu tokena (zestawy kluczy sieci Web JSON – JWKS) pod adresem https://OIDC_PROVIDER_URL/.well-known/openid-configuration.

Przyjrzyjmy się temu punktowi końcowemu. Możemy użyć polecenia aws eks description-cluster, aby uzyskać adres URL dostawcy OIDC.

$ IDP=$(aws eks describe-cluster --name eks-oidc-demo --query cluster.identity.oidc.issuer --output text)

 

# Reach the Discovery Endpoint

$ curl -s $IDP/.well-known/openid-configuration | jq -r '.'

{

  "issuer": "https://oidc.eks.eu-west-1.amazonaws.com/id/xxxx",

  "jwks_uri": "https://oidc.eks.eu-west-1.amazonaws.com/id/xxxx/keys",

  "authorization_endpoint": "urn:kubernetes:programmatic_authorization",

  "response_types_supported": [

    "id_token"

  ],

  "subject_types_supported": [

    "public"

  ],

  "claims_supported": [

    "sub",

    "iss"

  ],

  "id_token_signing_alg_values_supported": [

    "RS256"

  ]

}

W powyższym wyniku możesz zobaczyć pole jwks (JSON Web Key set), które zawiera zestaw kluczy zawierających klucze publiczne używane do weryfikacji JWT (JSON Web Token). Zapoznaj się z dokumentacją, aby uzyskać szczegółowe informacje na temat właściwości JWKS.

$ curl -s $IDP/keys | jq -r '.'

{

  "keys": [

    {

      "kty": "RSA",

      "e": "AQAB",

      "use": "sig",

      "kid": "b12d2f264e3eb3036bde33008066f24f9eafa28e",

      "alg": "RS256",

      "n": "xxx"

    },

    ...

  ]

}

Usługa IAM używa tych kluczy publicznych do weryfikacji tokena. Workflow wygląda następująco:

Aby zaakceptować token z poda, musi istnieć zaufanie ustanowione między IAM a dostawcą OIDC. Jeśli użyłeś eksctl do utworzenia klastra i przekazałeś flagę --with-OIDC, eksctl automatycznie ustanowi tę zaufaną relację. Jeśli nie przekazałeś flagi, tak jak i my w tym przewodniku, tę relację należy ustawić ręcznie.

Aby utworzyć relację zaufania, otwórz konsolę AWS i przejdź do IAM, następnie Identity Providers, a następnie dodaj Identity Provider.

1. Jako typ dostawcy wybierzemy OpenID Connect.
2. Podaj adres URL https://oidc.eks.eu-west-1.amazonaws.com/id/xxxx punktu końcowego dostawcy OIDC.
3. Wybierz Get Thumbprint.
4. Odbiorcy to sts.amazonaws.com.
5. Wybierz Add Provider.

Wreszcie możemy użyć naszego tokena w podzie Kubernetesa, aby uwierzytelnić się za pomocą API Amazon S3.

cat <<EOF | kubectl apply -f -

apiVersion: v1

kind: Pod

metadata:

  name: eks-iam-test4

spec:

  serviceAccountName: my-sa

  containers:

    - name: my-aws-cli

      image: amazon/aws-cli:latest

      args: ["s3", "ls"]

  restartPolicy: Never

EOF

Po kilku sekundach powinniśmy zobaczyć, że pod został pomyślnie zakończony. Sprawdzając logi poda, powinniśmy zobaczyć nasze buckety S3.

 

$ kubectl get pods

NAME                READY   STATUS      RESTARTS   AGE

eks-iam-test4       0/1     Completed   0          83s

 

$ kubectl logs eks-iam-test4

<s3 bucket list>

Czynności końcowe

Aby uniknąć ponoszenia przyszłych opłat, klaster EKS można usunąć za pomocą eksctl.

eksctl delete cluster \

  --name eks-oidc-demo \

  --region us-east-2

Podsumowanie

Mamy nadzieję, że podobała Ci się ta podróż i teraz dobrze rozumiesz, co naprawdę dzieje się za kulisami, gdy próbujemy uzyskać dostęp do usług AWS z Podów.

Widzieliśmy jak poświadczenia AWS będą domyślnie ustawiane na profil instancji EC2, jeśli workload nie może znaleźć żadnych poświadczeń, oraz jak konta usług Kubernetes i tokeny kont usług mogą być używane do nadawania Pods Identities.

Na koniec zobaczyliśmy, jak IAM może używać zewnętrznego dostawcy tożsamości OIDC i weryfikować tokeny w celu podania tymczasowych poświadczeń IAM.

Jeśli chcesz dowiedzieć się więcej, odwiedź na temat:

• Roli IAM dla Service Accounts, zobacz dokumentację.
• Tożsamości EKS webhook, zobacz Github Repository.
• Roadmap’y wszystkich funkcji i usług EKS, zobacz publiczny roadmap AWS.