Workload Identity vous permet d'attribuer des identités et une autorisation distinctes et précises pour chaque application du cluster. Workload Identity est la solution recommandée pour que les applications exécutées dans GKE sur AWS puissent accéder aux services AWS et Google Cloud. Pour en savoir plus, consultez la page concernant Workload Identity.
Cette rubrique explique comment créer un fournisseur OIDC, provisionner des comptes de service et tester un exemple de charge de travail à l'aide de Workload Identity.
Créer un fournisseur OIDC AWS IAM pour votre cluster
Pour utiliser Workload Identity avec votre cluster, vous devez d'abord créer un fournisseur OIDC AWS IAM qui référence votre cluster. Si vous disposez déjà d'un fournisseur IAM OIDC pour votre cluster, vous pouvez ignorer cette section.
Pour créer le fournisseur, procédez comme suit :
Déterminez l'URI d'émetteur OIDC pour votre cluster :
gcloud container aws clusters describe CLUSTER_NAME \ --location=GOOGLE_CLOUD_LOCATION \ --format='value(workloadIdentityConfig.issuerUri)'
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du clusterGOOGLE_CLOUD_LOCATION
: nom de l'emplacement Google Cloud à partir duquel ce pool de nœuds sera géré, comme défini dans les régions de gestion de Google Cloud.
Le résultat inclut l'URI d'émetteur OIDC de votre cluster. Enregistrez cette valeur pour l'étape suivante.
Créez ensuite un fournisseur OIDC AWS IAM qui référence votre cluster à l'aide de la commande suivante :
aws iam create-open-id-connect-provider \ --url ISSUER_URI \ --client-id-list sts.amazonaws.com \ --thumbprint-list 08745487e891c19e3078c1f2a07e452950ef36f6
Remplacez
ISSUER_URI
par votre URI d'émetteur de l'étape précédente.L'empreinte du service Google Cloud qui diffuse l'URI d'émetteur est toujours
08745487e891c19e3078c1f2a07e452950ef36f6
.
Configurer un rôle AWS IAM associé à une stratégie IAM
Pour configurer un rôle AWS IAM et lui associer une stratégie, procédez comme suit :
Déterminez l'hôte émetteur en supprimant le préfixe
https://
de l'URI de l'émetteur. Par exemple, si votre URI esthttps://oidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster
, l'hôte estoidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster
. Enregistrez cette valeur. Vous en aurez besoin ultérieurement.Déterminez le nom de ressource Amazon (ARN) du fournisseur en exécutant la commande suivante :
aws iam list-open-id-connect-providers --output=text \ --query 'OpenIDConnectProviderList[?ends_with(Arn, `ISSUER_HOST`) == `true`].Arn'
Remplacez
ISSUER_HOST
par le nom d'hôte de l'URI d'émetteur pour le cluster.Ensuite, créez une règle d'approbation pour fournir des identifiants OIDC au compte de service Kubernetes. Créez un fichier nommé
trust-policy.json
avec le contenu suivant :{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "PROVIDER_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "ISSUER_HOST:sub": "system:serviceaccount:NAMESPACE:KSA_NAME" } } } ] }
Remplacez les éléments suivants :
PROVIDER_ARN
: ARN du fournisseur OIDC IAM du clusterISSUER_HOST
: nom d'hôte de l'URI de l'émetteur pour le cluster.NAMESPACE
: espace de noms Kubernetes dans lequel l'application s'exécuteKSA_NAME
: compte de service Kubernetes (KSA) à utiliser pour l'application
Créez un rôle AWS IAM :
aws iam create-role --role-name=AWS_ROLE_NAME \ --assume-role-policy-document file://trust-policy.json
Remplacez
AWS_ROLE_NAME
par le nom du rôle AWS IAM pour l'application.Associez une stratégie AWS IAM au rôle :
aws iam attach-role-policy --role-name=AWS_ROLE_NAME \ --policy-arn=AWS_POLICY_ARN
Remplacez les éléments suivants :
-
AWS_ROLE_NAME
: nom du rôle IAM AWS pour l'application
Par exemple, pour créer un rôle nommé
ec2-readonly
, avec la stratégiearn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
, exécutez la commande suivante :aws iam attach-role-policy --role-name=ec2-readonly \ --policy-arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
-
Déploiement d'un exemple d'application
Pour tester Workload Identity, procédez comme suit pour déployer un exemple d'application :
Déterminez l'ARN du rôle :
aws iam get-role --role-name=AWS_ROLE_NAME --query 'Role.Arn'
Remplacez
AWS_ROLE_NAME
.Créez un fichier manifeste pour un espace de noms Kubernetes, un KSA et un pod. Copiez le fichier manifeste YAML suivant dans un fichier nommé
workload-identity-test.yaml
.apiVersion: v1 kind: Namespace metadata: name: NAMESPACE --- apiVersion: v1 kind: ServiceAccount metadata: name: KSA_NAME namespace: NAMESPACE automountServiceAccountToken: false --- apiVersion: v1 kind: Pod metadata: name: aws-cli-example namespace: NAMESPACE spec: serviceAccount: KSA_NAME containers: - name: aws-cli image: amazon/aws-cli:latest command: - /bin/bash - -c - "set -eu -o pipefail; while true; do aws ec2 describe-availability-zones; sleep 5; done" env: - name: AWS_ROLE_ARN value: AWS_ROLE_ARN - name: AWS_WEB_IDENTITY_TOKEN_FILE value: /var/run/secrets/aws-iam-token/serviceaccount/token - name: AWS_REGION value: AWS_REGION volumeMounts: - mountPath: /var/run/secrets/aws-iam-token/serviceaccount name: aws-iam-token readOnly: true volumes: - name: aws-iam-token projected: defaultMode: 420 sources: - serviceAccountToken: audience: sts.amazonaws.com expirationSeconds: 86400 path: token
Remplacez les éléments suivants :
NAMESPACE
KSA_NAME
AWS_ROLE_ARN
: ARN du rôle AWS IAM pour l'applicationAWS_REGION
: région AWS du cluster
Appliquer le fichier manifeste :
kubectl apply -f workload-identity-test.yaml
Attendez quelques minutes que le pod démarre, puis passez à la section suivante.
Vérifier que l'exemple d'application fonctionne
Pour vérifier que l'exemple d'application peut accéder à l'API EC2, consultez les journaux du pod :
kubectl logs -f aws-cli-example -n NAMESPACE
Si le pod peut accéder à l'API EC2, le résultat inclut des informations sur les zones de disponibilité EC2 et se présente comme suit :
-------------------------------------------------
| DescribeAvailabilityZones |
+-----------------------------------------------+
|| AvailabilityZones ||
|+---------------------+-----------------------+|
|| GroupName | us-west-2 ||
|| NetworkBorderGroup | us-west-2 ||
|| OptInStatus | opt-in-not-required ||
|| RegionName | us-west-2 ||
|| State | available ||
|| ZoneId | usw2-az1 ||
|| ZoneName | us-west-2a ||
|+---------------------+-----------------------+|
|| AvailabilityZones ||
|+---------------------+-----------------------+|
|| GroupName | us-west-2 ||
|| NetworkBorderGroup | us-west-2 ||
|| OptInStatus | opt-in-not-required ||
|| RegionName | us-west-2 ||
|| State | available ||
|| ZoneId | usw2-az2 ||
|| ZoneName | us-west-2b ||
|+---------------------+-----------------------+|
|| AvailabilityZones ||
|+---------------------+-----------------------+|
|| GroupName | us-west-2 ||
|| NetworkBorderGroup | us-west-2 ||
|| OptInStatus | opt-in-not-required ||
|| RegionName | us-west-2 ||
|| State | available ||
|| ZoneId | usw2-az3 ||
|| ZoneName | us-west-2c ||
|+---------------------+-----------------------+|
|| AvailabilityZones ||
|+---------------------+-----------------------+|
|| GroupName | us-west-2 ||
|| NetworkBorderGroup | us-west-2 ||
|| OptInStatus | opt-in-not-required ||
|| RegionName | us-west-2 ||
|| State | available ||
|| ZoneId | usw2-az4 ||
|| ZoneName | us-west-2d ||
|+---------------------+-----------------------+|
Effectuer un nettoyage
Pour supprimer cet exemple d'application, procédez comme suit :
Supprimez le fichier manifeste de l'exemple d'application de votre cluster :
kubectl delete -f workload-identity-test.yaml
Dissociez la stratégie AWS IAM du rôle :
aws iam detach-role-policy --role-name AWS_ROLE_NAME \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
Remplacez
AWS_ROLE_NAME
par le nom du rôle AWS IAM pour l'application.Supprimez le rôle AWS IAM :
aws iam delete-role --role-name AWS_ROLE_NAME
Remplacez
AWS_ROLE_NAME
par le nom du rôle AWS IAM pour l'application.Supprimez le fournisseur OIDC AWS IAM :
aws iam delete-open-id-connect-provider --open-id-connect-provider-arn PROVIDER_ARN
Remplacez
PROVIDER_ARN
par l'ARN du fournisseur OIDC IAM pour le cluster.
Étape suivante
- Découvrez comment utiliser Workload Identity avec les services Google Cloud.