Workload Identity de flota

Las aplicaciones a menudo necesitan autenticarse (proporcionar una identidad navegable) cuando se conectan a otros servicios. Por ejemplo, las aplicaciones deben autenticarse para usar las API de Google Cloud, como las de Compute Engine o las de AI Platform. En esta página, se explica cómo usar Workload Identity, la forma recomendada y más simple de que las cargas de trabajo de aplicaciones alojadas en una flota se autentiquen en las API y los servicios de Google Cloud. Puede obtener más información sobre las flotas y cómo lo ayudan a administrar su infraestructura y sus aplicaciones en Introducción a las flotas.

¿Qué es la identidad de la carga de flota de Workload Identity?

Las flotas usan la federación de Workload Identity para proporcionar a cada aplicación una identidad federada distinta que se puede usar a fin de autenticarse en Google Cloud y otros servicios que desarrollas. Las aplicaciones que se ejecutan en una flota reciben una identidad de carga de trabajo federada con el siguiente formato:

serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]

Aquí:

  • FLEET_PROJECT_ID.svc.id.goog es una representación con formato corto del grupo de Workload Identity para tu flota. Solo hay un grupo fijo de Workload Identity por flota y se crea de forma automática para ti.
  • K8S_NAMESPACE es el espacio de nombres de Kubernetes en el que se define la cuenta de servicio de Kubernetes.
  • KSA_NAME por el nombre de la cuenta de servicio de Kubernetes adjunta a la aplicación

Todas las aplicaciones alojadas en una flota comparten el mismo grupo de Workload Identity, lo que proporciona a las aplicaciones una identidad federada que se abstrae donde se aloja cada aplicación. Esto permite que una aplicación dentro de una flota acceda a un recurso (como una API de Google Cloud) solo una vez, en lugar de clúster por clúster, incluso si la aplicación se implementa en proyectos de Google Cloud o en diferentes nubes. Al igual que otras funciones habilitadas en la flota, esto se basa en el principio de flota de similitud, en el que los objetos de Kubernetes con el mismo nombre en diferentes clústeres se tratan de la misma manera. Entonces, por ejemplo, si tiene una aplicación con un backend implementado en varios clústeres en la misma flota y que necesita autenticarse en una API de Google, puede configurar su aplicación fácilmente a fin de que todos los servicios en el espacio de nombres "backend" puede acceder a esa API. Puede obtener más información sobre la forma en que las flotas usan la similitud, incluida la identidad de identidad, en Introducción a las flotas.

Los clústeres fuera de Google Cloud también pueden usar Workload Identity para proporcionar una identidad a fin de que el agente de Connect se autentique en Google. Puedes obtener más información sobre esto en Registra un clúster.

Antes de comenzar

  • Asegúrate de tener instaladas las siguientes herramientas de línea de comandos:

    • La versión más reciente del SDK de Cloud, que incluye gcloud, la herramienta de línea de comandos para interactuar con Google Cloud.
    • kubectl

    Si usas Cloud Shell como entorno de shell para interactuar con Google Cloud, estas herramientas están instaladas.

  • Asegúrate de haber inicializado la herramienta de línea de comandos de gcloud para usar con tu proyecto.

Configuración del clúster

Para que las aplicaciones de tu flota puedan recibir una identidad de carga de trabajo, los clústeres en los que se ejecuten deben registrarse en tu flota y estar configurados de forma adecuada para usar Workload Identity. La forma de hacerlo depende del tipo de clúster. Los clústeres de Anthos fuera de Google Cloud se registran de forma automática en la flota de proyectos cuando los creas. Los clústeres de GKE en Google Cloud y los clústeres adjuntos se deben registrar de forma manual.

Consulta la documentación de cada tipo de clúster para obtener más información sobre la configuración del clúster.

GKE

  1. Habilita GKE Workload Identity en tu clúster de Google Kubernetes Engine, si todavía no está habilitado.
  2. Sigue las instrucciones para registrar el clúster con Workload Identity.

Clústeres de Anthos fuera de Google Cloud

Los clústeres de Anthos en VMware, los clústeres de Anthos en equipos físicos y los clústeres de Anthos en AWS se registran de forma automática en tu flota de proyectos cuando los creas. A partir de Anthos 1.8, todos estos tipos de clústeres habilitan automáticamente Workload Identity cuando se registran. Existing registered clusters are updated to use Workload Identity when they are upgraded to Anthos 1.8.

Por el momento, los clústeres de Anthos en Azure deben registrarse de forma manual según las instrucciones que aparecen en Registra tu clúster con Connect. Estas instrucciones habilitan Workload Identity de forma predeterminada.

Clústeres adjuntos

Los clústeres vinculados se pueden registrar con Workload Identity habilitada si cumplen con los requisitos necesarios. Sigue las instrucciones para el tipo de clúster en Registra un clúster.

Usa una flota de Workload Identity

Después de registrar tu clúster, las cargas de trabajo implementadas en el clúster pueden usar identidades de carga de trabajo del grupo de Workload Identity. En esta sección, se muestra cómo usar la identidad de carga de trabajo para actuar en nombre de una cuenta de servicio de Google Cloud, de modo que las cargas de trabajo puedan acceder a las API de Google Cloud. Actuar como una cuenta de servicio es un caso de uso común para las identidades federadas, ya que permite que las cargas de trabajo se autentiquen en cualquier API de Google Cloud a la que tenga acceso la cuenta de servicio, lo que quita la carga de mantenimiento y seguridad de tener que administrar las claves de la cuenta de servicio para cada carga de trabajo.

Actúa en nombre de una cuenta de servicio

En esta sección, se muestra cómo configurar la identidad de la carga de trabajo federada de una aplicación para actuar como una cuenta de servicio mediante un archivo de credenciales predeterminadas de la aplicación en un ConfigMap, que incluye la creación y configuración de la cuenta de servicio con los permisos relevantes.

En el ejemplo, se usan los siguientes valores de marcador de posición:

  • WORKLOAD_IDENTITY_POOL es el grupo de Workload Identity asociado a tu flota. Como se muestra arriba, el valor de WORKLOAD_IDENTITY_POOL es FLEET_PROJECT_ID.svc.id.goog.
  • IDENTITY_PROVIDER es el nombre del proveedor de identidad asociado con tu clúster de Kubernetes.
  • K8S_NAMESPACE es el espacio de nombres de Kubernetes en el que se define la cuenta de servicio de Kubernetes.
  • KSA_NAME por el nombre de la cuenta de servicio de Kubernetes adjunta a la aplicación
  • GSA_NAME es el nombre de la cuenta de servicio de Google que actuará en tu aplicación.
  • GSA_PROJECT_ID es el ID del proyecto en el que se define la cuenta de servicio de Google.

A fin de configurar una identidad de carga de trabajo de la flota para actuar en nombre de una cuenta de servicio, haz lo siguiente:

  1. Asegúrese de que su clúster esté registrado en la flota mediante los pasos de la sección Configuración del clúster que se muestra arriba.

  2. Obtén los valores de WORKLOAD_IDENTITY_POOL y IDENTITY_PROVIDER del clúster registrado mediante la recuperación de los detalles de membresía de la flota del clúster, con el siguiente comando. Reemplaza MEMBERSHIP por el nombre de membresía único de tu clúster en la flota:

    gcloud container hub memberships describe MEMBERSHIP
    

    El resultado de la descripción de la membresía se ve de la siguiente manera (algunos campos se omitieron para mayor claridad):

    authority:
     identityProvider: IDENTITY_PROVIDER
     workloadIdentityPool: WORKLOAD_IDENTITY_POOL
    name: projects/FLEET_PROJECT_ID/locations/global/memberships/MEMBERSHIP
    
  3. Crea una cuenta de servicio de Google Cloud en la que tu aplicación pueda actuar como autenticación cuando se autentica en Google, si aún no tienes una:

    gcloud iam service-accounts create GSA_NAME --project=GSA_PROJECT_ID
    

    No es necesario que la cuenta de servicio esté en el proyecto host de tu flota. Puedes usar cualquier cuenta de servicio de Google Cloud en la organización. Puedes obtener más información sobre las cuentas de servicio y su funcionamiento en Cuentas de servicio.

  4. Asegúrate de haberle otorgado a la cuenta de servicio los permisos que necesita para acceder a las API de Google Cloud. Para ello, agrega las vinculaciones de política de IAM necesarias. Para ello, usa gcloud iam service-accounts add-iam-policy-binding o otro método si lo prefieres. Puedes averiguar qué permisos son necesarios para usar las API de Google Cloud en la documentación de cada servicio y ver una lista completa de las funciones predefinidas con los permisos necesarios en Comprende las funciones.

  5. A fin de autorizar la identidad de la carga de trabajo de tu aplicación para robar la identidad de la cuenta de servicio, crea una vinculación de política de IAM de la siguiente manera. Esta vinculación permite que la identidad de carga de trabajo federada de tu aplicación actúe como la cuenta de servicio de Google Cloud.

    gcloud iam service-accounts add-iam-policy-binding \
      GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com \
      --role=roles/iam.workloadIdentityUser \
      --member="serviceAccount:WORKLOAD_IDENTITY_POOL[K8S_NAMESPACE/KSA_NAME]"
    

    El campo --member representa la IAM de la identidad de la carga de trabajo federada de tu aplicación.

  6. Crea un ConfigMap que contenga el archivo de credenciales predeterminadas de la aplicación para tu carga de trabajo. Este archivo le indica a la biblioteca cliente compilada en su carga de trabajo cómo autenticarse en Google. El archivo de credenciales predeterminado de la aplicación contiene el grupo de identidades de la carga de trabajo relevante y la información de la cuenta de servicio, además de la ruta de acceso al token proyectado que se activará en el sistema de archivos del contenedor en el siguiente paso. GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com: La dirección de correo electrónico de la cuenta de servicio que representar.

    Esta configuración por sí sola no otorga acceso para actuar en nombre de la cuenta de servicio. Si la vinculación de IAM no existe, el Pod no podrá usar la cuenta de servicio.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      namespace: K8S_NAMESPACE
      name: my-cloudsdk-config
    data:
      config: |
        {
          "type": "external_account",
          "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER",
          "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken",
          "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
          "token_url": "https://sts.googleapis.com/v1/token",
          "credential_source": {
            "file": "/var/run/secrets/tokens/gcp-ksa/token"
          }
        }
    
  7. Sigue el ejemplo a continuación para configurar tu carga de trabajo. Ten en cuenta que el ConfigMap del paso anterior se activa en el sistema de archivos del contenedor como google-application-credentials.json, junto con un archivo de token de cuenta de servicio proyectado, en /var/run/secrets/tokens/gcp-ksa. Kubernetes emite los tokens proyectados y estos representan la identidad de la carga de trabajo dentro del clúster. Las bibliotecas cliente de Cloud intercambian estos tokens automáticamente para obtener tokens que pueden autenticarse con las API de Google. El campo audience del token proyectado debe establecerse en el valor WORKLOAD_IDENTITY_POOL.

    kind: Namespace
    apiVersion: v1
    metadata:
      name:  K8S_NAMESPACE
    ---
    kind: ServiceAccount
    apiVersion: v1
    metadata:
      namespace:  K8S_NAMESPACE
      name: KSA_NAME
    automountServiceAccountToken: false
    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
      namespace:  K8S_NAMESPACE
    spec:
      serviceAccountName: KSA_NAME
      containers:
      - name: my-container
        image: my-image
        env:
          - name: GOOGLE_APPLICATION_CREDENTIALS
            value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
        volumeMounts:
        - name: gcp-ksa
          mountPath: /var/run/secrets/tokens/gcp-ksa
          readOnly: true
      volumes:
      - name: gcp-ksa
        projected:
          defaultMode: 420
          sources:
          - serviceAccountToken:
              path: token
              audience: WORKLOAD_IDENTITY_POOL
              expirationSeconds: 172800
          - configMap:
              name: my-cloudsdk-config
              optional: false
              items:
                - key: "config"
                  path: "google-application-credentials.json"
    
    

Autentica desde tu código

Las bibliotecas cliente de Cloud controlan automáticamente la autenticación en Google Cloud cuando las usas para acceder a los servicios de Google desde tu código. Para usar la configuración que se muestra arriba en tus aplicaciones, debes usar las bibliotecas cliente de Cloud que admiten la Federación de Workload Identity. A continuación, se muestran las versiones mínimas de bibliotecas cliente de Cloud requeridas, además de las instrucciones para verificar tu versión actual:

C++

La mayoría de las bibliotecas cliente de Google Cloud para C++ admiten la federación de identidades mediante un objeto ChannelCredentials, que se crea mediante una llamada a grpc::GoogleDefaultCredentials(). Para inicializar esta credencial, debes compilar las bibliotecas cliente con la versión 1.36.0 o posterior de gRPC.

La biblioteca cliente de Cloud Storage para C++ usa la API de REST, no gRPC, por lo que no admite la federación de identidades.

Comienza a usarlo

Las bibliotecas cliente para Go admiten la federación de identidades si usan la versión v0.0.0-20210218202405-ba52d332ba99 o una versión posterior del módulo golang.org/x/oauth2.

Para verificar qué versión de este módulo usa tu biblioteca cliente, ejecuta los siguientes comandos:

cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

Java

Las bibliotecas cliente para Java admiten la federación de identidades si usan la versión 0.24.0 o posterior del artefacto com.google.auth:google-auth-library-oauth2-http.

Para verificar qué versión de este artefacto usa tu biblioteca cliente, ejecuta el siguiente comando de Maven en el directorio de tu aplicación:

mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

Node.js

Las bibliotecas cliente de Node.js admiten la federación de identidades si usan la versión 7.0.2 o una versión posterior del paquete google-auth-library.

Para verificar qué versión de este paquete usa tu biblioteca cliente, ejecuta el siguiente comando en el directorio de tu aplicación:

npm list google-auth-library

Cuando creas un objeto GoogleAuth, puedes especificar un ID del proyecto o puedes permitir que GoogleAuth encuentre el ID del proyecto de forma automática. Para encontrar el ID del proyecto de manera automática, la cuenta de servicio en el archivo de configuración debe tener la función de Navegador (roles/browser) o una función con permisos equivalentes en tu proyecto. Para obtener más información, consulta el README del paquete google-auth-library.

Python

Las bibliotecas cliente para Python admiten la federación de identidades si usan la versión 1.27.0 o posterior del paquete google-auth.

Para verificar qué versión de este paquete usa tu biblioteca cliente, ejecuta el siguiente comando en el entorno en el que está instalado el paquete:

pip show google-auth

Si deseas especificar un ID del proyecto para el cliente de autenticación, puedes configurar la variable de entorno GOOGLE_CLOUD_PROJECT o permitir que el cliente busque el ID del proyecto de forma automática. Para encontrar el ID del proyecto de manera automática, la cuenta de servicio en el archivo de configuración debe tener la función de Navegador (roles/browser) o una función con permisos equivalentes en tu proyecto. Para obtener más información, consulta la guía del usuario del paquete google-auth.