Usa Workload Identity de la 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 API de Compute Engine o AI Platform. En esta página se explica cómo usar Workload Identity de la flota, la forma más simple y recomendada para que las cargas de trabajo de aplicaciones alojadas en una flota se autentiquen en las API y los servicios de Google Cloud.

¿Qué es Workload Identity de la flota?

Workload Identity de la flota extiende la funcionalidad proporcionada en Workload Identity de GKE, que permite que las cargas de trabajo de tu clúster se autentiquen en Google sin necesidad de descargarlas, rotarlas de forma manual y, en general, administrar las claves de las cuentas de servicio de Google Cloud. En su lugar, las cargas de trabajo se autentican mediante tokens de corta duración generados por el clúster. Todos los clústeres con GKE Workload Identity habilitado usan el grupo de identidades de cargas de trabajo de su proyecto cuando emiten ID, lo que permite que la administración de identidades y accesos confíe y comprenda las credenciales de la cuenta de servicio de Kubernetes. Puedes obtener más información sobre Workload Identity de GKE en Usa Workload Identity.

Con las flotas, los clústeres registrados pueden obtener el beneficio adicional de usar Workload Identity de flota. Los clústeres registrados con Workload Identity habilitada en su membresía de flota pueden usar el grupo de Workload Identity de flota, lo que facilita la configuración de la autenticación para las API de Google y otros servicios en la flota y en varios proyectos. El agente de Connect también puede usar Workload Identity de flota en algunos tipos de clústeres para autenticarse en Google como parte de la membresía de la flota. Además, es necesario usar algunas funciones de GKE Enterprise que funcionan en varios proyectos, como Anthos Service Mesh.

Cómo funciona

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 desarrolles. 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 de identidades de carga de trabajo fijo por flota y se crea de forma automática.
  • 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 para 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. Por ejemplo, si tienes una aplicación con un backend implementado en varios clústeres de la misma flota y que necesita autenticarse en una API de Google, puedes configurar la aplicación con facilidad para que todos los servicios el espacio de nombres “backend” puede acceder a esa API. Puedes obtener mucha más información sobre cómo las flotas usan la similitud, incluida la similitud de identidad, en Cómo funcionan 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 qué tipos de clústeres usan Workload Identity de la flota en la sección Configuración del clúster a continuación.

Antes de comenzar

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

    • La versión más reciente de Google Cloud CLI, 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 CLI de gcloud para usarla en tu proyecto.

Configuración del clúster

Antes de que las aplicaciones de tu flota puedan recibir una identidad de carga de trabajo, los clústeres en los que se ejecutan deben registrarse en tu flota y estar configurados de forma correcta para usar Workload Identity. La forma de hacerlo depende del tipo de clúster. Los clústeres de GKE 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 Workload Identity de GKE en tu clúster de Google Kubernetes Engine, si aún no está habilitado.
  2. Sigue las instrucciones para registrar el clúster mediante Workload Identity.

Clústeres de GKE fuera de Google Cloud

Los GKE en VMware, GKE en Bare Metal y los clústeres de GKE de múltiples nubes (en AWS y Azure) se registran automáticamente en la flota de tu proyecto en el clúster hora de creación. A partir de GKE Enterprise 1.8, todos estos tipos de clústeres habilitan automáticamente Workload Identity de la flota cuando se registran. Los clústeres registrados existentes se actualizan para usar Workload Identity cuando se actualizan a GKE Enterprise o una versión posterior.

Clústeres adjuntos

Los clústeres adjuntos de EKS y AKS registrados con la API de GKE Multi-cloud se registran con Workload Identity de la flota habilitada de forma predeterminada. Otros clústeres vinculados se pueden registrar con Workload Identity de la flota habilitada si cumplen con los requisitos necesarios. Sigue las instrucciones para el tipo de clúster en Registra un clúster.

Usa Workload Identity de la flota

Después de registrar el clúster, las cargas de trabajo implementadas en él pueden usar las identidades de carga de trabajo del grupo de identidades de carga de trabajo de la flota. 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 a fin de que tus 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 usará 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. Sigue los pasos de la sección Configuración del clúster anterior para asegurarte de que tu clúster esté registrado en la flota.

  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 fleet 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 cómo funcionan en Cuentas de servicio.

  4. Asegúrate de que otorgaste a la cuenta de servicio los permisos que necesita para acceder a las API de Google Cloud. Para ello, agrega las vinculaciones de políticas de IAM necesarias. Para ello, usa gcloud iam service-accounts add-iam-policy-binding o usa 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. Crea una vinculación de política de IAM a fin de autorizar a la identidad de carga de trabajo de tu aplicación para que actúe en nombre de la cuenta de servicio. 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 es la representación de IAM de la identidad de la carga de trabajo federada de tu aplicación.

  6. Crea un ConfigMap que contenga el archivo 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 predeterminadas 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 es 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 con Google para obtener tokens que pueden autenticarse con las API de Google. El campo audience del token proyectado debe establecerse en el valor de 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"

Realiza la autenticación desde el código

Las bibliotecas cliente de Cloud controlan la autenticación a Google Cloud de forma automática 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.

Go

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 automáticamente. Para encontrar el ID del proyecto de manera automática, la cuenta de servicio en el archivo de configuración debe tener el rol de Navegador (roles/browser) o un rol 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 automáticamente. Para encontrar el ID del proyecto de manera automática, la cuenta de servicio en el archivo de configuración debe tener el rol de Navegador (roles/browser) o un rol con permisos equivalentes en tu proyecto. Para obtener más información, consulta la guía del usuario del paquete google-auth.