El 2 de noviembre, se lanzó una nueva versión de GKE en AWS. Consulta las notas de la versión para obtener más información.

Crea un clúster de usuario con identidad de carga de trabajo

Workload Identity te permite vincular cuentas de servicio de Kubernetes a cuentas de IAM de AWS con permisos específicos. En este tema, se muestra cómo habilitar la identidad de carga de trabajo para GKE en las cargas de trabajo de AWS.

Workload Identity usa permisos de IAM de AWS para bloquear el acceso no deseado a los recursos de la nube. Con la identidad de la carga de trabajo, puedes asignar diferentes funciones de IAM a cada carga de trabajo. Este control detallado de los permisos te permite seguir el principio de mínimo privilegio.

Sin la identidad de la carga de trabajo, asigna funciones de IAM de AWS a tu GKE en los nodos de AWS. Todas las cargas de trabajo en esos nodos tienen acceso completo a los permisos del nodo.

Para habilitar la identidad de la carga de trabajo en tu clúster, debes completar los siguientes pasos: Un administrador de clúster o un desarrollador debe completar los pasos.

Administrador del clúster

  1. Crea un depósito de Cloud Storage para almacenar datos de descubrimiento de OIDC.
  2. Crea un clúster de usuario con identidad de carga de trabajo habilitada.
  3. Crea un webhook en tu clúster que aplique credenciales de identidad de carga de trabajo a los pods en la creación o, de lo contrario, configura las variables de entorno de forma manual.
  4. Configura el proveedor de OIDC de AWS.
  5. Crea políticas y funciones de IAM de AWS.
Administrador o desarrollador de clústeres
  1. Crea cuentas de servicio de Kubernetes y vincula las políticas de AWS.
Desarrollador
  1. Aplica credenciales a tus pods.

Personas

En este documento, se hace referencia a los siguientes individuos:

  • Administrador de clústeres: Esta persona crea uno o más clústeres de usuario y archivos de configuración de autenticación para los desarrolladores que los usan.

  • Desarrollador: esta persona ejecuta cargas de trabajo en uno o más clústeres.

Requisitos previos

Para completar los pasos de este documento, debes tener la siguiente configuración:

  • Un servicio de administración de GKE en AWS
  • Clústeres de usuarios que ejecutan una versión de Kubernetes superior a 1.17.9-gke.2800
  • Los siguientes permisos y herramientas

Permisos

Para crear un clúster con la identidad de carga de trabajo habilitada, necesitas los siguientes permisos:

Google Cloud

  • Crea un depósito de Cloud Storage legible de forma pública con el acceso uniforme a nivel de depósito habilitado.
  • Otorga permisos de lectura y escritura de management-sa@PROJECT_NAME.iam.gserviceaccount.com al depósito.

AWS

  • Crear un proveedor de OIDC de AWS
  • Crea funciones de IAM de AWS

Herramientas

En tu máquina local, Google recomienda tener la herramienta de jq instalada.

Crea el depósito de detección de OIDC

Esta sección está destinada a los administradores de clústeres.

Tu AWSCluster necesita almacenar los datos de detección de OIDC en un depósito de Cloud Storage de acceso público. El depósito incluye la configuración de detección de OIDC y claves públicas. AWS usa el contenido para autenticar las solicitudes de GKE en clústeres de AWS.

Tu depósito debe tener los siguientes atributos:

Si no tienes un depósito con estos atributos, crea uno con los siguientes comandos gsutil:

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

Reemplaza BUCKET_NAME con el nombre de tu depósito nuevo.

Otorga permisos de cuenta de servicio de administración

La cuenta de servicio de administración de identidades y accesos para el servicio de administración de GKE en AWS necesita permisos para leer y escribir objetos en este depósito. Otorga los permisos de tu cuenta de servicio de administración con el siguiente comando de gsutil.

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

Reemplaza PROJECT_NAME por el nombre del proyecto.

Crear un clúster de usuario

Esta sección está destinada a los administradores de clústeres.

Crear un clúster de usuario con la identidad de carga de trabajo habilitada

Crea un clúster de usuarios que contenga detalles sobre tu depósito de descubrimiento de OIDC. Establece esta información en el campo spec.controlPlane.workloadIdentity.oidcDiscoveryGCSBucket de AWSCluster.

En este ejemplo, se crea un clúster de forma manual de las CRD de AWSCluster y AWSNodePool.

  1. Cambia al directorio con la configuración de GKE en AWS. Creaste este directorio cuando instalaste el servicio de administración.

    cd anthos-aws

  2. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio de administración.

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

  3. Abre un editor de texto y copia la siguiente definición de AWSCluster en un archivo llamado 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.17.9-gke.2800
        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:
          membershipName: ANTHOS_CONNECT_NAME
        workloadIdentity:
          oidcDiscoveryGCSBucket: WORKLOAD_IDENTITY_BUCKET
    

    Reemplaza lo siguiente:

    • CLUSTER_NAME:
    • AWS_REGION: la región de AWS en la que se ejecuta tu clúster.
    • VPC_ID: El ID de la VPC en la que se ejecuta tu clúster.
    • POD_ADDRESS_CIDR_BLOCKS: el rango CIDR de las direcciones IPv4 que usan los pods del clúster.
    • SERVICE_ADDRESS_CIDR_BLOCKS: el rango de direcciones IPv4 que usan los servicios del clúster.
    • SERVICE_LOAD_BALANCER_SUBNETS: los ID de subred en los que GKE en AWS puede crear balanceadores de cargas públicos o privados.
    • GKE_VERSION:
    • AWS_INSTANCE_TYPE: un tipo de instancia compatible
    • SSH_KEY_NAME: un par de claves de AWS EC2.
    • CONTROL_PLANE_SUBNET_IDS: los ID de subred de los AZ en los que se ejecutarán tus instancias del plano de control.
    • CONTROL_PLANE_SECURITY_GROUPS:
    • CONTROL_PLANE_IAM_ROLE:
    • control-plane-iam-profile por el nombre del perfil de instancia de AWS EC2 asignado a las réplicas del plano de control.
    • ROOT_VOLUME_SIZE: el tamaño, en gibibyte (GiB), de los volúmenes raíz del plano de control.
    • ETCD_VOLUME_SIZE: el tamaño de los volúmenes que usa etc.
    • ARN_OF_KMS_KEY: La clave de AWS KMS que se usa para encriptar los secretos del clúster.
    • El nombre de la membresía de ANTHOS_CONNECT_NAMEConnect que se usa para registrar tu clúster. El nombre de la membresía debe ser único. Por ejemplo, projects/YOUR_PROJECT/locations/global/memberships/CLUSTER-_AME, en el que YOUR_PROJECT es tu proyecto de Google Cloud y CLUSTER-_AME es un nombre único en tu proyecto.
    • WORKLOAD_IDENTITY_BUCKET: el nombre del depósito de Cloud Storage que contiene la información de descubrimiento de identidad de carga de trabajo.
  4. Crea uno o más AWSNodePools para tu clúster. Abre un editor de texto y copia la siguiente definición de AWSCluster en un archivo llamado 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.17.9-gke.2800
      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
      labels:
        LABEL_NAME: LABEL_VALUE
      taints:
      - key: KEY1
        value: VALUE1
        effect: PREFERNOSCHEDULE
      - key: KEY2
        effect: NOSCHEDULE
      tags:
        TAG_NAME: TAG_VALUE
    

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: un nombre único para tu AWSNodePool.
    • AWSCLUSTER_NAME: Es el nombre de tu AWSCluster. Por ejemplo staging-cluster.
    • GKE_VERSION: una versión de GKE compatible con AWS
    • AWS_REGION: La misma región de AWS que tu AWSCluster.
    • AWS_SUBNET_ID: una subred de AWS en la misma región que tu MINIMUM_NODE_COUNT y MAXIMUM_NODE_COUNT con la cantidad mínima y máxima de nodos en el grupo de nodos.
    • MINIMUM_NODE_COUNT:
    • MAXIMUM_NODE_COUNT:
    • MAXIMUM_PODS_PER_NODE_COUNT: Es la cantidad máxima de pods que GKE on AWS asignará a un nodo.
    • AWS_NODE_TYPE: un tipo de instancia de AWS EC2
    • KMS_KEY_PAIR_NAME: Es el par de claves de AWS KMS asignado a cada trabajador del grupo de nodos.
    • NODE_IAM_PROFILE: Es el nombre del perfil de la instancia de AWS EC2 asignado a los nodos del grupo.
    • ROOT_VOLUME_SIZE: el tamaño, en gibibyte (GiB), de los volúmenes raíz del plano de control.
    • LABEL_NAME:
    • LABEL_VALUE:
    • KEY1:
    • VALUE1:
    • PREFERNOSCHEDULE:
    • KEY2:
    • NOSCHEDULE:
    • TAG_NAME:
    • TAG_VALUE:

Cree un kubeconfig

Mientras se inicia el clúster de usuario, puedes crear un contexto kubeconfig para el clúster de usuario nuevo. Usas el contexto para autenticarte en un usuario o clúster de administración.

  1. Usa anthos-gke aws clusters get-credentials a fin de generar un kubeconfig para el clúster de usuario en ~/.kube/config.

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

    Reemplaza CLUSTER_NAME por el nombre del clúster. Por ejemplo, cluster-0

  2. Usa kubectl para autenticarte en el clúster de usuario nuevo.

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

    Si el clúster está listo, el resultado incluye las URL de los componentes de Kubernetes dentro del clúster.

Visualiza el estado del clúster

El servicio de administración aprovisiona recursos de AWS cuando aplicas un AWSCluster o AWSNodePool.

  1. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio de administración.

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

  2. Para enumerar los clústeres, usa kubectl get AWSClusters.

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

El resultado incluye el nombre, el estado, la antigüedad, la versión y el extremo de cada clúster.

Por ejemplo, el siguiente resultado incluye solo un AWSCluster llamado cluster-0:

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

Consulte los eventos de su clúster

Para ver los eventos de Kubernetes recientes de tu clúster de usuario, usa kubectl get events.

  1. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio de administración.

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

  2. Ejecuta kubectl get events.

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

El resultado incluye información, advertencias y errores relacionados con el servicio de administración.

Crea el webhook de identidad de la carga de trabajo o configura variables de entorno

Esta sección está destinada a los administradores de clústeres.

Para proporcionar credenciales de identidad de carga de trabajo a tus cargas de trabajo sin configuración adicional, puedes crear un webhook en tus clústeres de usuarios (AWSCluster) de manera opcional. Este webhook intercepta las solicitudes de creación de pods y establece la siguiente información de IAM de AWS como variables de entorno:

  • AWS_ROLE_ARN: el nombre del recurso de Amazon (ARN) de la función de IAM
  • aws-iam-token: El token que se intercambia para las credenciales de IAM de AWS
  • AWS_WEB_IDENTITY_TOKEN_FILE: La ruta de acceso en la que se almacena el token

Con estas variables, la interfaz de línea de comandos o el SDK de AWS que se ejecutan dentro del pod pueden acceder a los recursos otorgados a la función de AWS.

Crear el webhook es opcional. Si decides no crear el webhook, debes configurar las variables de entorno que se mencionaron antes en el pod. Para obtener más información sobre cómo no usar un webhook, consulta Aplica credenciales sin el webhook.

Crea los archivos YAML para el webhook

Para implementar el webhook, realiza los siguientes pasos:

  1. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio de administración.

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

  2. Obtén el nombre del clúster de usuarios con kubectl:

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

    kubectl enumera todos tus clústeres de usuarios. Elige el clúster de usuario que creaste con la identidad de carga de trabajo habilitada.

    CLUSTER_NAME=CLUSTER_NAME
    

    Reemplaza CLUSTER_NAME por el nombre del clúster. Por ejemplo, cluster-0

  3. Configura variables de entorno para el espacio de nombres y la imagen del pod de identidad de la carga de trabajo.

    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. Para generar el manifiesto YAML de webhook en un archivo llamado aws-webhook.yaml, realiza los siguientes pasos.

    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
    

    El contenido de aws-webhook.yaml está listo para aplicarse a tu clúster.

Aplica el webhook a tu clúster de usuario

Para aplicar el webhook a tu clúster de usuarios, realiza los siguientes pasos:

  1. Aplica el archivo aws-webhook.yaml en tu clúster de usuario.

    env HTTP_PROXY=http://localhost:8118 \
    kubectl apply -f aws-webhook.yaml
    
  2. Cuando aplicas el manifiesto, el pod webhook genera solicitudes de firma de certificados de Kubernetes (CSR). Aprueba todas las solicitudes de system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook con 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. Verifique que no haya ningún CSR pendiente no aprobado.

    Usa kubectl get csr para verificar que todos los CSR del solicitante system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook estén aprobados:

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

    Respuesta:

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

Configura el proveedor de OIDC de AWS

Esta sección está destinada a los administradores de clústeres.

Para crear un proveedor de OIDC en AWS, AWS requiere que el usuario proporcione una autoridad certificada intermedia (CA) o certificado de servidor intermedio, incluso si el certificado del servidor está firmado por una CA pública. Tus credenciales de detección de OIDC se almacenan en storage.googleapis.com, con un certificado firmado por una CA intermedia llamada GTS CA 1O1. Esta CA vence al 12/15/2021 00:00:42 GMT. La huella digital SHA-1 de su CA intermedia GTS CA 1O1 es dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2.

Para registrar tu depósito de descubrimiento de OIDC como proveedor de OIDC con AWS, sigue estos pasos:

  1. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio de administración.

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

  2. Guarda la URL del emisor de OIDC, la ruta de acceso del host del emisor y la huella digital de Cloud Storage en las variables de entorno.

    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. Usa la herramienta aws para crear un proveedor de OIDC en AWS.

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

Actualizar la huella digital

Si Google rota la CA para storage.googleapis.com, ejecuta los siguientes comandos: 1. Busca la huella digital del certificado actualizada, dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2.

  1. Actualiza la huella digital con el comando aws.bash aws iam update-open-id-connect-provider-thumbprint

Crea funciones y políticas de IAM de AWS

Esta sección está destinada a los administradores de clústeres.

Crea una función IAM de AWS para vincularla a una cuenta de servicio de Kubernetes. La función de IAM tiene permisos para sts:AssumeRoleWithWebIdentity.

Para crear la función, realiza los siguientes pasos:

  1. Busca o crea una política de IAM de AWS que otorgue los permisos necesarios para las cargas de trabajo.

    Necesitas la política de IAM de AWS para el nombre de recurso de Amazon (ARN). Por ejemplo, arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.

  2. Para crear la cuenta de servicio de Kubernetes y vincular la política de IAM de AWS, ejecuta la siguiente secuencia de comandos:

    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}
    

    Reemplaza lo siguiente:

    • KUBERNETES_SERVICE_ACCOUNT: es el nombre de la cuenta de servicio de Kubernetes nueva.
    • WORKLOAD_IDENTITY_NAMESPACE: es el nombre del espacio de nombres donde se ejecutan las cargas de trabajo.
    • AWS_ROLE_NAME: es el nombre de una función nueva de AWS.
    • EXISTING_AWS_POLICY: el nombre del recurso de Amazon (ARN) de una política de IAM de AWS existente. Por ejemplo, arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.

Crea cuentas de servicio de Kubernetes para cargas de trabajo

Esta sección está destinada a desarrolladores o administradores de clústeres.

Para crear cuentas de servicio de Kubernetes vinculadas a la función de IAM de AWS que se especificó antes, realiza los siguientes pasos:

  1. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu clúster de usuario.

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

  2. Crea la cuenta de servicio de Kubernetes mediante la ejecución de los siguientes comandos:

    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}
    

    Reemplaza lo siguiente:

    • AWS_ROLE_NAME: el nombre de la función de IAM de AWS que se aplica a tus cargas de trabajo
    • WORKLOAD_IDENTITY_NAMESPACE: es el nombre del espacio de nombres donde se ejecutan las cargas de trabajo.

Aplica credenciales a tus pods

Esta sección está destinada a los desarrolladores.

En esta sección, se da por hecho que implementaste la identidad de la carga de trabajo webhook. Si no has implementado el webhook, ve directamente a la sección sobre cómo aplicar credenciales sin el webhook.

Aplica credenciales con el webhook

En esta sección, se describe cómo configurar los pods para leer las credenciales que ofrece el webhook.

Agregue la cuenta de servicio al pod

Para usar la identidad de la carga de trabajo con una carga de trabajo, agrega la cuenta de servicio de Kubernetes a los siguientes campos:

  • Para una implementación: spec.template.spec.serviceAccountName
  • Para un pod: spec.serviceAccount

En el siguiente manifiesto de pod, se inicia una imagen de CentOS básica y contiene el campo 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

Reemplaza lo siguiente:

  • WORKLOAD_IDENTITY_NAMESPACE: es el nombre del espacio de nombres donde se ejecutan las cargas de trabajo.
  • KUBERNETES_SERVICE_ACCOUNT: el nombre de la cuenta de servicio de Kubernetes que creaste antes

Verifique si los pods tienen configuradas las variables de entorno

A fin de verificar si los pods tienen configuradas las variables de entorno, ejecuta el siguiente comando para obtener la información del pod:

kubectl get pod --namespace WORKLOAD_IDENTITY_NAMESPACE POD_NAME -o yaml

Reemplaza lo siguiente:

  • WORKLOAD_IDENTITY_NAMESPACE: es el nombre del espacio de nombres donde se ejecutan las cargas de trabajo.
  • POD_NAME: el nombre del pod que se va a comprobar

El resultado contiene los valores de las variables de entorno en spec.containers.command.env y el punto de activación para el token de IAM de AWS. A continuación, se muestra un ejemplo del manifiesto de un 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:
  ...

Aplica credenciales sin el webhook

Si no implementas la webhook de identidad de carga de trabajo, debes hacer lo siguiente:

Crear un pod con credenciales para la identidad de la carga de trabajo

A fin de crear un pod que incluya las credenciales necesarias para la identidad de la carga de trabajo, realiza los siguientes pasos:

  1. Copia el manifiesto de pod siguiente en un archivo llamado sample-pod-no-webhook.yaml. La configuración inicia una imagen de CentOS básica con las credenciales necesarias.

    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
    

    Reemplaza lo siguiente:

    • WORKLOAD_IDENTITY_NAMESPACE: es el nombre del espacio de nombres donde se ejecutan las cargas de trabajo.
    • IAM_ROLE_ARN: el ARN de la función de IAM otorgada al pod. Por ejemplo, arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.
    • KUBERNETES_SERVICE_ACCOUNT: es el nombre de la cuenta de servicio de Kubernetes que creaste antes.
  2. Aplica el manifiesto de pod a tu clúster con kubectl:

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

Compruebe si los pods pueden acceder a los recursos de AWS

En el siguiente procedimiento, se describe cómo comprobar si el pod recibió las credenciales necesarias para que funcione la identidad de la carga de trabajo.

Para completar los pasos, debes contar con lo siguiente:

  • Acceso de shell bash al contenedor; La mayoría de las imágenes en producción no tienen una shell disponible. El siguiente ejemplo muestra cómo usar el pod especificado anteriormente para acceder a AWS S3.

  • Tu pod necesita tener acceso saliente a Internet para descargar la interfaz de línea de comandos de AWS.

Para verificar si el pod puede acceder a un depósito de S3, realice los siguientes pasos:

  1. Usa kubectl exec para iniciar una shell Bash interactiva en el pod sample-centos-pod-no-webhook:

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

    Su terminal abre el shell Bash en el pod.

  2. Usa pip para instalar la interfaz de línea de comandos de AWS:

    curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && python get-pip.py
    pip install awscli --upgrade
    
  3. Verifica los permisos y las credenciales de IAM de AWS con la herramienta de 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
    

    Reemplaza IAM_ROLE_ARN con el ARN de la función de IAM otorgada al pod. Por ejemplo, arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

    La herramienta de aws muestra información similar a la que se muestra a continuación:

    {
        "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 ves el siguiente mensaje, verifica que el depósito sea de acceso público: An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements

Realice una limpieza

En esta sección, se muestra cómo quitar recursos que se crearon antes en este documento.

Limpia la cuenta de servicio y su función de IAM asociada.

Para borrar la cuenta de servicio y su función de IAM asociada, realiza los siguientes pasos:

  1. Limpia la cuenta de servicio:

    kubectl delete sa KUBERNETES_SERVICE_ACCOUNT --namespace WORKLOAD_IDENTITY_NAMESPACE
    

    Reemplaza lo siguiente:

    • KUBERNETES_SERVICE_ACCOUNT: el nombre de la cuenta de servicio de Kubernetes nueva
    • WORKLOAD_IDENTITY_NAMESPACE: es el nombre del espacio de nombres donde se ejecutan las cargas de trabajo.
  2. Limpia la función de IAM de AWS mediante el siguiente comando de shell bash o la IU web de AWS:

    • aws iam  detach-role-policy \
        --role-name=${AWS_ROLE_NAME} \
        --policy-arn=${AWS_POLICY}
      aws iam delete-role --role-name=${AWS_ROLE_NAME}
      
    • La función IAM de AWS también se puede borrar mediante la IU web.

Borra tu clúster de usuario

Para borrar tu clúster de usuario, sigue los pasos en Desinstala GKE en AWS.

Limpia el proveedor de OIDC de AWS

Después de borrar el clúster de usuario, anula el registro y borra el proveedor de OIDC en AWS mediante el siguiente comando del shell bash o la IU web de AWS.

  1. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio de administración.

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

  2. Borra el proveedor de OIDC de AWS mediante la ejecución de los siguientes comandos:

    • 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}
      
    • La función IAM de AWS también se puede borrar mediante la IU web.

    Recibirás una confirmación de que se borró el proveedor de OIDC de AWS.

¿Qué sigue?