Une nouvelle version d'Anthos clusters on AWS (GKE sur AWS) a été publiée le 3 février. Pour en savoir plus, consultez les notes de version.

Créer un cluster d'utilisateur avec Workload Identity

Workload Identity vous permet d'associer des comptes de service Kubernetes à des comptes AWS IAM avec des autorisations spécifiques. Cette rubrique explique comment activer Workload Identity pour vos charges de travail de clusters Anthos sur AWS.

Workload Identity se sert des autorisations AWS IAM pour bloquer les accès indésirables aux ressources cloud. Avec Workload Identity, vous pouvez attribuer différents rôles IAM à chaque charge de travail. Ce contrôle précis des autorisations vous permet de suivre le principe du moindre privilège.

Sans Workload Identity, vous attribuez des rôles AWS IAM à vos noeuds de clusters Anthos sur AWS. Toutes les charges de travail sur ces nœuds ont alors un accès complet aux autorisations du nœud.

Pour activer Workload Identity pour votre cluster, procédez comme suit : Les étapes sont séparées par les personas qui les exécutent : un administrateur de cluster ou un développeur.

Administrateur du cluster

  1. Créez un bucket Cloud Storage pour stocker les données de découverte OIDC.
  2. Créez un cluster d'utilisateur avec Workload Identity activé.
  3. Créez un webhook sur votre cluster qui applique des identifiants Workload Indentity aux pods lors de la création. Si vous ne souhaitez pas utiliser le webhook, vous pouvez définir manuellement des variables d'environnement.
  4. Configurez le fournisseur AWS OIDC.
  5. Créez des rôles et stratégies AWS IAM.
Administrateur ou développeur de cluster
  1. Créez des comptes de service Kubernetes et associez-leur des stratégies AWS.
Développeur
  1. Appliquez des identifiants à vos pods.

Personas

Ce document fait référence aux personas suivantes :

  • Administrateur de cluster : cette personne crée un ou plusieurs clusters d'utilisateur et crée des fichiers de configuration d'authentification pour les développeurs qui utilisent les clusters.

  • Développeur : cette personne exécute des charges de travail sur un ou plusieurs clusters.

Prérequis

Pour réaliser la procédure décrite dans ce document, vous devez effectuer les opérations suivantes :

  • Un service de gestion de cluster Anthos sur AWS.
  • Clusters d'utilisateurs exécutant une version de Kubernetes supérieure à 1.17.9.
  • Les autorisations et outils suivants.

Autorisations

Pour créer un cluster avec Workload Identity activé, vous devez disposer des autorisations suivantes :

Google Cloud

  • Créez un bucket Cloud Storage lisible publiquement avec l'accès uniforme au niveau du bucket activé.
  • Accordez des autorisations de lecture/écriture à management-sa@PROJECT_NAME.iam.gserviceaccount.com sur le bucket.

AWS

  • Créer un fournisseur AWS OIDC
  • Créer des rôles AWS IAM

Outils

Sur votre ordinateur local, nous vous recommandons d'installer l'outil jq.

Créer le bucket de découverte OIDC

Cette section s'adresse aux administrateurs de cluster.

Votre AWSCluster doit stocker les données de découverte OIDC dans un bucket Cloud Storage accessible au public. Le bucket inclut une configuration de découverte et des clés publiques OIDC. AWS utilise le contenu pour authentifier les requêtes de vos clusters d'utilisateurs.

Votre bucket doit comporter les attributs suivants :

Si vous n'avez pas de bucket avec ces attributs, créez-en un à l'aide des commandes gsutil suivantes :

BUCKET=BUCKET_NAME
gsutil mb -b on gs://${BUCKET}
gsutil iam ch allUsers:objectViewer gs://${BUCKET}

Remplacez BUCKET_NAME par le nom de votre nouveau bucket.

Accorder des autorisations au compte de service de gestion

Le compte de service Identity and Access Management pour le service de gestion des clusters Anthos sur AWS nécessite des autorisations pour lire et écrire des objets dans ce bucket. Accordez les autorisations de votre compte de service de gestion à l'aide de la commande gsutil suivante.

MANAGEMENT_SA=management-sa@PROJECT_NAME.iam.gserviceaccount.com
gsutil iam ch serviceAccount:${MANAGEMENT_SA}:admin gs://${BUCKET}

Remplacez PROJECT_NAME par le nom de votre projet.

Créer un cluster d'utilisateur

Cette section s'adresse aux administrateurs de cluster.

Créer un cluster d'utilisateur avec Workload Identity activé

Créez un cluster d'utilisateur contenant des détails sur votre bucket de découverte OIDC. Vous définissez ces informations dans le champ spec.controlPlane.workloadIdentity.oidcDiscoveryGCSBucket de votre fichier AWSCluster.

Dans cet exemple, vous créez un cluster manuellement à partir des objets CRD AWSCluster et AWSNodePool.

  1. Accédez au répertoire de votre configuration Anthos clusters sur AWS. Vous avez créé ce répertoire lors de l'installation du service de gestion.

    cd anthos-aws

  2. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre service de gestion.

    cd anthos-aws
    anthos-gke aws management get-credentials

  3. Ouvrez un éditeur de texte et copiez la définition AWSCluster suivante dans un fichier nommé staging-cluster.yaml.

    apiVersion: multicloud.cluster.gke.io/v1
    kind: AWSCluster
    metadata:
      name: CLUSTER_NAME
    spec:
      region: AWS_REGION
      networking:
        vpcID: VPC_ID
        podAddressCIDRBlocks: POD_ADDRESS_CIDR_BLOCKS
        serviceAddressCIDRBlocks: SERVICE_ADDRESS_CIDR_BLOCKS
        ServiceLoadBalancerSubnetIDs: SERVICE_LOAD_BALANCER_SUBNETS
      controlPlane:
        version: GKE_VERSION # Latest version is 1.18.10-gke.900
        instanceType: AWS_INSTANCE_TYPE
        keyName: SSH_KEY_NAME
        subnetIDs:
        - CONTROL_PLANE_SUBNET_IDS
        securityGroupIDs:
        - CONTROL_PLANE_SECURITY_GROUPS
        iamInstanceProfile: CONTROL_PLANE_IAM_ROLE
        rootVolume:
          sizeGiB: ROOT_VOLUME_SIZE
        etcd:
          mainVolume.sizeGIB: ETCD_VOLUME_SIZE
        databaseEncryption:
          kmsKeyARN: ARN_OF_KMS_KEY
        hub: # Optional
          membershipName: ANTHOS_CONNECT_NAME
        workloadIdentity: # Optional
          oidcDiscoveryGCSBucket: WORKLOAD_IDENTITY_BUCKET
    

    Remplacez l'élément suivant :

    • CLUSTER_NAME : nom du cluster
    • AWS_REGION : région AWS dans laquelle le cluster s'exécute.

    • VPC_ID : ID du VPC dans lequel votre cluster s'exécute.

    • POD_ADDRESS_CIDR_BLOCKS : plage CIDR d'adresses IPv4 utilisées par les pods du cluster. . La plage doit être comprise dans la plage d'adresses CIDR de votre VPC, et non dans un sous-réseau. Exemple : 10.2.0.0/16.

    • SERVICE_ADDRESS_CIDR_BLOCKS : plage d'adresses IPv4 utilisée par les services du cluster. . La plage doit être comprise dans la plage d'adresses CIDR de votre VPC, et non dans un sous-réseau. Exemple : 10.1.0.0/16.

    • SERVICE_LOAD_BALANCER_SUBNETS : ID des sous-réseaux sur lesquels les clusters Anthos sur AWS peuvent créer des équilibreurs de charge publics ou privés.

    • GKE_VERSION : version de Kubernetes compatible avec les clusters Anthos sur AWS. La version la plus récente est 1.18.10-gke.900.

    • AWS_INSTANCE_TYPE : type d'instance EC2 compatible.

    • SSH_KEY_NAME : paire de clé AWS EC2.

    • CONTROL_PLANE_SUBNET_IDS : ID de sous-réseau dans les zones de disponibilité où vos instances de plan de contrôle sont exécutées.

    • CONTROL_PLANE_SECURITY_GROUPS : ID de groupe de sécurité créé lors de l'installation du service de gestion. Vous pouvez personnaliser ce paramètre en ajoutant tous les identifiants de groupe de sécurité requis pour la connexion au plan de contrôle.

    • CONTROL_PLANE_IAM_PROFILE : nom du profil d'instance AWS EC2 attribué aux instances dupliquées du plan de contrôle.

    • ROOT_VOLUME_SIZE : taille, en gibioctet (Gio) des volumes racines de votre plan de contrôle.

    • ETCD_VOLUME_SIZE : taille de vos volumes utilisés par etcd.

    • ARN_OF_KMS_KEY : clé AWS KMS utilisée pour chiffrer les secrets du cluster.

    • ANTHOS_CONNECT_NAME : nom d'appartenance Connect utilisé pour enregistrer votre cluster. Le nom de l'appartenance doit être unique. Par exemple, projects/YOUR_PROJECT/locations/global/memberships/CLUSTER-_AME, où YOUR_PROJECT est votre projet Google Cloud et CLUSTER-NAME est un nom unique dans votre projet. Ce champ est facultatif.

    • WORKLOAD_IDENTITY_BUCKET : nom du bucket Cloud Storage contenant vos informations de découverte Workload Identity. Ce champ est facultatif.

  4. Créez un ou plusieurs pools AWSNodePools pour votre cluster. Ouvrez un éditeur de texte et copiez la définition AWSCluster suivante dans un fichier nommé staging-nodepools.yaml.

    apiVersion: multicloud.cluster.gke.io/v1
    kind: AWSNodePool
    metadata:
      name: NODE_POOL_NAME
    spec:
      clusterName: AWSCLUSTER_NAME
      version: GKE_VERSION # latest version is 1.18.10-gke.900
      region: AWS_REGION
      subnetID: AWS_SUBNET_ID
      minNodeCount: MINIMUM_NODE_COUNT
      maxNodeCount: MAXIMUM_NODE_COUNT
      maxPodsPerNode: MAXIMUM_PODS_PER_NODE_COUNT
      instanceType: AWS_NODE_TYPE
      keyName: KMS_KEY_PAIR_NAME
      iamInstanceProfile: NODE_IAM_PROFILE
      rootVolume:
        sizeGiB: ROOT_VOLUME_SIZE
    

    Remplacez l'élément suivant :

    • NODE_POOL_NAME : un nom unique pour votre pool AWSNodePool ;
    • AWSCLUSTER_NAME : nom du cluster AWSCluster. Exemple : staging-cluster.
    • GKE_VERSION : version de GKE compatible avec les clusters Anthos sur AWS.
    • AWS_REGION : même région AWS que votre AWSCluster.
    • AWS_SUBNET_ID : sous-réseau AWS situé dans la même région que votre cluster AWS. MINIMUM_NODE_COUNT et MAXIMUM_NODE_COUNT avec le nombre minimal et maximal de nœuds dans le pool de nœuds.
    • MINIMUM_NODE_COUNT : nombre minimal de nœuds dans le pool de nœuds. Pour en savoir plus, consultez la page Procéder au scaling des clusters d'utilisateur.
    • MAXIMUM_NODE_COUNT : nombre maximal de nœuds dans le pool de nœuds.
    • MAXIMUM_PODS_PER_NODE_COUNT : nombre maximal de pods que les clusters Anthos sur AWS peuvent allouer à un nœud.
    • AWS_NODE_TYPE : un type d'instance AWS EC2.
    • KMS_KEY_PAIR_NAME : Paire de clés KMS AWS attribuée à chaque nœud de calcul de pool de nœuds.
    • NODE_IAM_PROFILE : Nom du profil d'instance AWS EC2 attribué aux nœuds du pool.
    • ROOT_VOLUME_SIZE : taille, en gibioctet (Gio) des volumes racines de votre plan de contrôle.

Créer un fichier kubeconfig

Pendant le démarrage de votre cluster d'utilisateur, vous pouvez créer un contexte kubeconfig pour votre nouveau cluster d'utilisateur. Vous utilisez ce contexte pour vous authentifier auprès d'un utilisateur ou d'un cluster de gestion.

  1. Utilisez anthos-gke aws clusters get-credentials pour générer un objet kubeconfig pour votre cluster d'utilisateur dans ~/.kube/config.

    env HTTP_PROXY=http://localhost:8118 \
      anthos-gke aws clusters get-credentials CLUSTER_NAME
    

    Remplacez CLUSTER_NAME par le nom de votre cluster. Exemple : cluster-0.

  2. Utilisez kubectl pour vous authentifier auprès de votre nouveau cluster d'utilisateur.

    env HTTP_PROXY=http://localhost:8118 \
      kubectl cluster-info
    

    Si votre cluster est prêt, le résultat inclut les URL des composants Kubernetes qu'il contient.

Afficher l'état de votre cluster

Le service de gestion provisionne les ressources AWS lorsque vous appliquez un élément AWSCluster ou AWSNodePool.

  1. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre service de gestion.

    cd anthos-aws
    anthos-gke aws management get-credentials

  2. Pour répertorier vos clusters, utilisez kubectl get AWSClusters.

    env HTTP_PROXY=http://localhost:8118 \
      kubectl get AWSClusters
    

Le résultat inclut le nom, l'état, l'âge, la version et le point de terminaison de chaque cluster.

Par exemple, le résultat suivant n'inclut qu'un seul AWSCluster nommé cluster-0 :

NAME        STATE          AGE     VERSION         ENDPOINT
cluster-0   Provisioning   2m41s   1.18.10-gke.900   gke-xyz.elb.us-east-1.amazonaws.com

Afficher les événements de votre cluster

Pour afficher les événements Kubernetes récents de votre cluster d'utilisateur, utilisez kubectl get events.

  1. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre service de gestion.

    cd anthos-aws
    anthos-gke aws management get-credentials

  2. Exécutez kubectl get events.

    env HTTP_PROXY=http://localhost:8118 \
      kubectl get events
    

Le résultat inclut des informations, des avertissements et des erreurs liés à votre service de gestion.

Créer le webhook Workload Identity ou définir des variables d'environnement

Cette section s'adresse aux administrateurs de cluster.

Pour fournir les identifiants Workload Identity à vos charges de travail sans configuration supplémentaire, vous pouvez éventuellement créer un webhook sur vos clusters d'utilisateurs (AWSCluster). Ce webhook intercepte les demandes de création de pod et définit les informations AWS IAM suivantes en tant que variables d'environnement :

  • AWS_ROLE_ARN : nom de la ressource Amazon (ARN) du rôle IAM
  • aws-iam-token : jeton échangé pour les identifiants AWS IAM
  • AWS_WEB_IDENTITY_TOKEN_FILE : chemin d'accès au jeton stocké

Avec ces variables, l'interface de ligne de commande ou le SDK AWS s'exécutant dans le pod peut accéder aux ressources attribuées au rôle AWS.

La création du webhook est facultative. Si vous décidez de ne pas créer de webhook, vous devez définir les variables d'environnement répertoriées précédemment dans le pod. Pour plus d'informations sur l'utilisation d'un webhook, consultez la section Appliquer des identifiants sans le webhook.

Créer les fichiers YAML pour le webhook

Pour déployer le webhook, procédez comme suit :

  1. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre service de gestion.

    cd anthos-aws
    anthos-gke aws management get-credentials

  2. Obtenez le nom du cluster d'utilisateur avec kubectl :

    env HTTP_PROXY=http://localhost:8118 \
    kubectl get awscluster
    

    kubectl répertorie tous vos clusters d'utilisateurs. Choisissez le cluster d'utilisateur que vous avez créé avec Workload Identity activé.

    CLUSTER_NAME=CLUSTER_NAME
    

    Remplacez CLUSTER_NAME par le nom de votre cluster. Exemple : cluster-0.

  3. Définissez des variables d'environnement pour l'image de pod et l'espace de noms de Workload Identity.

    IDENTITY_IMAGE=gcr.io/gke-multi-cloud-release/amazon-eks-pod-identity-webhook:release-0.2.2-gke.0
    
    WEBHOOK_NAMESPACE=workload-identity-webhook
    
  4. Générez le fichier manifeste YAML du webhook dans un fichier nommé aws-webhook.yaml en procédant comme suit :

    env HTTP_PROXY=http://localhost:8118 \
    anthos-gke aws clusters get-credentials ${CLUSTER_NAME}
    
    CLUSTER_CA=$(env HTTP_PROXY=http://localhost:8118 \
    kubectl config view --raw -o json  | jq -r '.clusters[] | select(.name == "'$(kubectl config current-context)'") | .cluster."certificate-authority-data"')
    
    cat << EOF > aws-webhook.yaml
    apiVersion: v1
    kind: Namespace
    metadata:
      name: ${WEBHOOK_NAMESPACE}
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: pod-identity-webhook
      namespace: ${WEBHOOK_NAMESPACE}
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: pod-identity-webhook
      namespace: ${WEBHOOK_NAMESPACE}
    rules:
      - apiGroups: ['']
        resources: ['secrets']
        verbs: ['create']
      - apiGroups: ['']
        resources: ['secrets']
        verbs: ['get', 'update', 'patch']
        resourceNames:
          - pod-identity-webhook
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: pod-identity-webhook
      namespace: ${WEBHOOK_NAMESPACE}
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: pod-identity-webhook
    subjects:
      - kind: ServiceAccount
        name: pod-identity-webhook
        namespace: ${WEBHOOK_NAMESPACE}
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: pod-identity-webhook
    rules:
      - apiGroups: ['']
        resources: ['serviceaccounts']
        verbs: ['get', 'watch',  'list']
      - apiGroups:  ['certificates.k8s.io']
        resources: ['certificatesigningrequests']
        verbs:  ['create', 'get', 'list', 'watch']
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: pod-identity-webhook
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: pod-identity-webhook
    subjects:
      - kind: ServiceAccount
        name: pod-identity-webhook
        namespace: ${WEBHOOK_NAMESPACE}
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: pod-identity-webhook
      namespace: ${WEBHOOK_NAMESPACE}
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: pod-identity-webhook
      template:
        metadata:
          labels:
            app: pod-identity-webhook
        spec:
          serviceAccountName: pod-identity-webhook
          containers:
            - name: pod-identity-webhook
              image: ${IDENTITY_IMAGE}
              imagePullPolicy: Always
              command:
                - /webhook
                - --in-cluster
                - --namespace=${WEBHOOK_NAMESPACE}
                - --service-name=pod-identity-webhook
                - --tls-secret=pod-identity-webhook
                - --annotation-prefix=eks.amazonaws.com
                - --token-audience=sts.amazonaws.com
                - --logtostderr
              volumeMounts:
                - name: webhook-certs
                  mountPath: /var/run/app/certs
                  readOnly: false
          volumes:
            - name: webhook-certs
              emptyDir: {}
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: pod-identity-webhook
      namespace: ${WEBHOOK_NAMESPACE}
      annotations:
        prometheus.io/port: '443'
        prometheus.io/scheme: https
        prometheus.io/scrape: 'true'
    spec:
      ports:
        - port: 443
          targetPort: 443
      selector:
        app: pod-identity-webhook
    ---
    apiVersion: admissionregistration.k8s.io/v1beta1
    kind: MutatingWebhookConfiguration
    metadata:
      name: pod-identity-webhook
      namespace: ${WEBHOOK_NAMESPACE}
    webhooks:
      - name: pod-identity-webhook.amazonaws.com
        failurePolicy: Ignore
        clientConfig:
          service:
            name: pod-identity-webhook
            namespace: ${WEBHOOK_NAMESPACE}
            path: /mutate
          caBundle: ${CLUSTER_CA}
        rules:
          - operations: ['CREATE']
            apiGroups: ['']
            apiVersions: ['v1']
            resources: ['pods']
    EOF
    

    Le contenu de aws-webhook.yaml est prêt à être appliqué à votre cluster.

Appliquer le webhook à votre cluster d'utilisateur

Pour appliquer le webhook à votre cluster d'utilisateur, procédez comme suit :

  1. Appliquez le fichier aws-webhook.yaml à votre cluster d'utilisateur.

    env HTTP_PROXY=http://localhost:8118 \
    kubectl apply -f aws-webhook.yaml
    
  2. Lorsque vous appliquez le fichier manifeste, le pod de webhook génère des demandes de signature de certificat Kubernetes (CSR). Approuver toutes les demandes de system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook avec kubectl certificate approve.

    kubectl certificate approve $(env HTTP_PROXY=http://localhost:8118 \
    kubectl get csr -o \
      jsonpath="{.items[?(@.spec.username==\"system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook\")].metadata.name}")
    
  3. Vérifiez qu'il n'existe aucune demande de signature de certificat client non approuvée.

    Utilisez kubectl get csr pour vérifier que toutes les CSR du demandeur system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook sont approuvées :

    env HTTP_PROXY=http://localhost:8118 \
    kubectl get csr
    

    Réponse :

    NAME        AGE   REQUESTOR                                            CONDITION
    csr-mxrt8   10s   system:serviceaccount:default:pod-identity-webhook   Approved,Issued
    

Configurer le fournisseur AWS OIDC

Cette section s'adresse aux administrateurs de cluster.

Pour créer un fournisseur OIDC sur AWS, AWS requiert une autorité de certification intermédiaire ou une empreinte de certification de serveur. Vos identifiants de découverte OIDC sont stockés sur storage.googleapis.com, avec un certificat signé par une autorité de certification intermédiaire nommée GTS CA 1O1. Cette autorité de certification arrive à expiration le 15/12/2021 à 00:00:42 UTC. L'empreinte SHA-1 de son autorité de certification intermédiaire GTS CA 1O1 est dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2.

Pour enregistrer votre bucket de découverte OIDC en tant que fournisseur OIDC avec AWS, procédez comme suit :

  1. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre service de gestion.

    cd anthos-aws
    anthos-gke aws management get-credentials

  2. Enregistrez l'URL de l'émetteur OIDC, le chemin d'hôte de l'émetteur et l'empreinte Cloud Storage dans les variables d'environnement.

    ISSUER_URL=$(env HTTP_PROXY=http://localhost:8118 \
    kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.workloadIdentityInfo.issuerURL}')
    ISSUER_HOSTPATH=${ISSUER_URL#"https://"}
    CA_THUMBPRINT=dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2
    
  3. Utilisez l'outil aws pour créer un fournisseur OIDC sur AWS.

    aws iam create-open-id-connect-provider \
      --url ${ISSUER_URL} \
      --thumbprint-list ${CA_THUMBPRINT} \
      --client-id-list sts.amazonaws.com
    

Mettre à jour l'empreinte

Si Google effectue une rotation de l'autorité de certification pour storage.googleapis.com, exécutez les commandes suivantes : 1. Recherchez l'empreinte du certificat mise à jour, dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2.

  1. Mettez à jour l'empreinte avec la commande aws. bash aws iam update-open-id-connect-provider-thumbprint

Créer des rôles et des stratégies AWS IAM

Cette section s'adresse aux administrateurs de cluster.

Créer un rôle AWS IAM pour lier un compte de service Kubernetes Le rôle IAM dispose des autorisations pour sts:AssumeRoleWithWebIdentity.

Pour créer le rôle, procédez comme suit :

  1. Recherchez ou créez une stratégie AWS IAM, qui accorde les autorisations nécessaires pour vos charges de travail.

    Vous avez besoin de la stratégie AWS IAM du nom de ressource Amazon (ARN) de la stratégie. Exemple : arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.

  2. Pour créer le compte de service Kubernetes et lui associer la stratégie AWS IAM, exécutez le script suivant :

    KSA_NAME=KUBERNETES_SERVICE_ACCOUNT
    WORKLOAD_NAMESPACE=WORKLOAD_IDENTITY_NAMESPACE
    
    AWS_ROLE_NAME=AWS_ROLE_NAME
    AWS_POLICY=EXISTING_AWS_POLICY
    
    # Get the ID of the user cluster
    anthos-gke aws management get-credentials
    
    CLUSTER_ID=$(env HTTP_PROXY=http://localhost:8118 \
    kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}')
    
    # Get the ID Provider ARN
    PROVIDER_ARN=$(aws iam list-open-id-connect-providers  \
    | jq '.OpenIDConnectProviderList' \
    | jq ".[] | select(.Arn |  contains(\"${CLUSTER_ID}\"))"   \
    | jq  '.Arn' | tr -d '"')
    
    # Create AWS role and policy
    cat > irp-trust-policy.json << EOF
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "${PROVIDER_ARN}"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "${ISSUER_HOSTPATH}:sub": "system:serviceaccount:${WORKLOAD_NAMESPACE}:${KSA_NAME}"
            }
          }
        }
      ]
    }
    EOF
    aws iam create-role \
      --role-name ${AWS_ROLE_NAME} \
      --assume-role-policy-document file://irp-trust-policy.json
    aws iam update-assume-role-policy \
      --role-name ${AWS_ROLE_NAME} \
      --policy-document file://irp-trust-policy.json
    aws iam attach-role-policy \
      --role-name ${AWS_ROLE_NAME} \
      --policy-arn ${AWS_POLICY}
    

    Remplacez l'élément suivant :

    • KUBERNETES_SERVICE_ACCOUNT : nom du nouveau compte de service Kubernetes.
    • WORKLOAD_IDENTITY_NAMESPACE : nom de l'espace de noms où les charges de travail sont exécutées.
    • AWS_ROLE_NAME : nom d'un nouveau rôle AWS.
    • EXISTING_AWS_POLICY : nom de ressource Amazon (ARN) d'une stratégie AWS IAM existante. Exemple : arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.

Créer des comptes de service Kubernetes pour les charges de travail

Cette section est destinée aux développeurs ou aux administrateurs de cluster.

Pour créer des comptes de service Kubernetes liés au rôle AWS IAM précédemment spécifié, procédez comme suit :

  1. Dans votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre cluster d'utilisateur.

    cd anthos-aws
    env HTTP_PROXY=http://localhost:8118 \
    anthos-gke aws clusters get-credentials CLUSTER_NAME

  2. Créez le compte de service Kubernetes en exécutant les commandes suivantes :

    S3_ROLE_ARN=$(aws iam get-role \
      --role-name AWS_ROLE_NAME \
      --query Role.Arn --output text)
    
    cat << EOF  > k8s-service-account.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: ${KSA_NAME}
      namespace: WORKLOAD_IDENTITY_NAMESPACE
    EOF
    
    env HTTP_PROXY=http://localhost:8118 \
    kubectl apply -f k8s-service-account.yaml
    
    env HTTP_PROXY=http://localhost:8118 \
    kubectl annotate sa --namespace ${WORKLOAD_NAMESPACE} ${KSA_NAME} eks.amazonaws.com/role-arn=${S3_ROLE_ARN}
    

    Remplacez l'élément suivant :

    • AWS_ROLE_NAME : nom du rôle AWS IAM à appliquer à vos charges de travail
    • WORKLOAD_IDENTITY_NAMESPACE : nom de l'espace de noms où les charges de travail sont exécutées

Appliquer des identifiants à vos pods

Cette section s'adresse aux développeurs.

Dans cette section, nous partons du principe que vous avez déployé le webhook Workload Identity. Si vous n'avez pas déployé le webhook, passez à la section Appliquer des identifiants sans webhook.

Appliquer des identifiants avec le webhook

Cette section explique comment configurer vos pods pour qu'ils lisent les identifiants mis à disposition par le webhook.

Ajouter le compte de service au pod

Pour utiliser Workload Identity avec une charge de travail, ajoutez le compte de service Kubernetes dans les champs suivants :

  • Pour un déploiement : spec.template.spec.serviceAccountName
  • Pour un pod : spec.serviceAccount

Le fichier manifeste de pod suivant lance une image CentOS de base et contient le champ spec.serviceAccount.

apiVersion: v1
kind: Pod
metadata:
  name: sample-centos-pod
  namespace: WORKLOAD_IDENTITY_NAMESPACE
spec:
  containers:
  - command:
    - /bin/bash
    - -ec
    - while :; do echo '.'; sleep 500 ; done
    image: centos:7
    name: centos
  serviceAccount: KUBERNETES_SERVICE_ACCOUNT

Remplacez l'élément suivant :

  • WORKLOAD_IDENTITY_NAMESPACE : nom de l'espace de noms où les charges de travail sont exécutées
  • KUBERNETES_SERVICE_ACCOUNT : nom du compte de service Kubernetes que vous avez créé précédemment

Vérifier si les variables d'environnement sont définies pour les pods

Pour vérifier si les variables d'environnement ont été définies pour les pods, exécutez la commande suivante afin d'obtenir les informations sur le pod :

kubectl get pod --namespace WORKLOAD_IDENTITY_NAMESPACE POD_NAME -o yaml

Remplacez l'élément suivant :

  • WORKLOAD_IDENTITY_NAMESPACE : nom de l'espace de noms où les charges de travail sont exécutées
  • POD_NAME : nom du pod à vérifier

La sortie contient les valeurs des variables d'environnement dans spec.containers.command.env et le point d'installation du jeton AWS IAM. Voici un exemple de fichier manifeste de pod :

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  containers:
  - command:
    - /bin/bash
    - -ec
    - while :; do echo '.'; sleep 500 ; done
    env:
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::1234567890:role/my-example-workload-role-1
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    image: centos:7
    imagePullPolicy: IfNotPresent
    name: centos
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: my-k8s-serviceaccount-token-d4nz4
      readOnly: true
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  serviceAccount: my-k8s-serviceaccount
  serviceAccountName: my-k8s-serviceaccount
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
  - name: my-k8s-serviceaccount-token-d4nz4
    secret:
      defaultMode: 420
      secretName: my-k8s-serviceaccount-token-d4nz4
   ...
status:
  ...

Appliquer des identifiants sans le webhook

Si vous ne déployez pas le webhook Workload Identity, procédez comme suit :

Créer un pod avec des identifiants pour Workload Identity

Pour créer un pod comprenant les identifiants nécessaires pour Workload Identity, procédez comme suit :

  1. Copiez le fichier manifeste de pod suivant dans un fichier nommé sample-pod-no-webhook.yaml. La configuration lance une image CentOS de base avec les identifiants nécessaires.

    apiVersion: v1
    kind: Pod
    metadata:
      name: sample-centos-pod-no-webhook
      namespace: WORKLOAD_IDENTITY_NAMESPACE
    spec:
      containers:
      - command:
        - /bin/bash
        - -ec
        - while :; do echo '.'; sleep 500 ; done
        image: centos:7
        name: centos
        env:
        - name: AWS_ROLE_ARN
          value: IAM_ROLE_ARN
        - name: AWS_WEB_IDENTITY_TOKEN_FILE
          value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
        volumeMounts:
        - mountPath: /var/run/secrets/eks.amazonaws.com/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
      serviceAccount: KUBERNETES_SERVICE_ACCOUNT
    

    Remplacez l'élément suivant :

    • WORKLOAD_IDENTITY_NAMESPACE : nom de l'espace de noms où les charges de travail sont exécutées.
    • IAM_ROLE_ARN : ARN du rôle IAM attribué au pod. Exemple : arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.
    • KUBERNETES_SERVICE_ACCOUNT : nom du compte de service Kubernetes que vous avez créé précédemment.
  2. Appliquez le fichier manifeste de pod à votre cluster à l'aide de kubectl :

    env HTTP_PROXY=http://localhost:8118 \
    kubectl apply -f sample-pod-no-webhook.yaml
    

Vérifier si les pods peuvent accéder aux ressources AWS

La procédure suivante explique comment vérifier si le pod a reçu les identifiants nécessaires pour que Workload Identity fonctionne.

Pour terminer la procédure, vous devez disposer des éléments suivants :

  • Accès de l'interface système bash au conteneur ; la plupart des images de production n'ont pas d'interface système. L'exemple suivant montre comment utiliser le pod spécifié dans la section précédente pour accéder à AWS S3.

  • Votre pod doit disposer d'un accès sortant à Internet pour télécharger l'interface de ligne de commande AWS.

Pour vérifier si le pod peut accéder à un bucket S3, procédez comme suit :

  1. Utilisez kubectl exec pour lancer une interface système bash interactive sur le pod sample-centos-pod-no-webhook :

    env HTTP_PROXY=http://localhost:8118 \
    kubectl exec -it --namespace ${WORKLOAD_NAMESPACE} sample-centos-pod-no-webhook -- bash
    

    Votre terminal ouvre l'interface système bash sur le pod.

  2. Utilisez pip pour installer l'interface de ligne de commande AWS :

    curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && python get-pip.py
    pip install awscli --upgrade
    
  3. Vérifiez les autorisations et les identifiants AWS IAM à l'aide de l'outil aws :

    aws sts assume-role-with-web-identity \
     --role-arn IAM_ROLE_ARN \
     --role-session-name mh9test \
     --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token \
     --duration-seconds 1000
    

    Remplacez IAM_ROLE_ARN par l'ARN du rôle IAM attribué au pod. Exemple : arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.

    L'outil aws imprime des informations d'identification semblables à celles-ci :

    {
        "AssumedRoleUser": {
            "AssumedRoleId": "AROAR2ZZZLEXVSDCDJ37N:mh9test",
            "Arn": "arn:aws:sts::126285863215:assumed-role/my-example-workload-role-1/mh9test"
        },
        "Audience": "sts.amazonaws.com",
        "Provider": "arn:aws:iam::126285863215:oidc-provider/storage.googleapis.com/gke-issuer-cec6c353",
        "SubjectFromWebIdentityToken": "system:serviceaccount:default:my-s3-reader-ksa",
        "Credentials": {
            "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
            "SessionToken": "MY_TOKEN",
            "Expiration": "2020-08-14T22:46:36Z",
            "AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
        }
    }
    

    Si le message suivant s'affiche, vérifiez que le bucket est accessible au public : An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements

Nettoyer

Cette section explique comment supprimer les ressources créées précédemment dans ce document.

Nettoyer le compte de service et son rôle IAM associé

Pour supprimer le compte de service et son rôle IAM associé, procédez comme suit :

  1. Nettoyez le compte de service :

    kubectl delete sa KUBERNETES_SERVICE_ACCOUNT --namespace WORKLOAD_IDENTITY_NAMESPACE
    

    Remplacez l'élément suivant :

    • KUBERNETES_SERVICE_ACCOUNT : nom du nouveau compte de service Kubernetes
    • WORKLOAD_IDENTITY_NAMESPACE : nom de l'espace de noms où les charges de travail sont exécutées
  2. Nettoyez le rôle IAM AWS. Sélectionnez l'une des options suivantes :

    • Supprimez le rôle AWS IAM à l'aide de la console AWS.

    • Supprimez le rôle à l'aide de l'outil de ligne de commande AWS à l'aide des commandes suivantes :

      aws iam  detach-role-policy \
        --role-name=${AWS_ROLE_NAME} \
        --policy-arn=${AWS_POLICY}
      aws iam delete-role --role-name=${AWS_ROLE_NAME}
      

Supprimer votre cluster d'utilisateur

Pour supprimer votre cluster utilisateur, suivez la procédure décrite dans la section Désinstaller les clusters Anthos sur AWS.

Nettoyer le fournisseur AWS OIDC

Une fois le cluster d'utilisateur supprimé, annulez l'enregistrement du fournisseur OIDC et supprimez-le sur AWS à l'aide de la commande shell bash suivante ou de l'interface utilisateur Web AWS.

  1. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre service de gestion.

    cd anthos-aws
    anthos-gke aws management get-credentials

  2. Supprimez le rôle à l'aide de l'outil de ligne de commande AWS avec les commandes suivantes :

    CLUSTER_ID=$(env HTTP_PROXY=http://localhost:8118 \
    kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}')
    
    PROVIDER_ARN=$(aws iam list-open-id-connect-providers  \
    | jq '.OpenIDConnectProviderList' \
    | jq ".[] | select(.Arn |  contains(\"${CLUSTER_ID}\"))"   \
    | jq  '.Arn' | tr -d '"')
    
    aws iam delete-open-id-connect-provider \
        --open-id-connect-provider-arn=${PROVIDER_ARN}
    

    Vous recevez une confirmation de la suppression du fournisseur AWS OIDC.

Étape suivante