Introducción a la identidad del servicio

En esta página, se describen las dos identidades de Cloud Run y cómo las bibliotecas cliente de Cloud usan la identidad del servicio para llamar a las Google Cloud APIs. Entre los ejemplos de Google Cloud productos que tienen bibliotecas cliente de Cloud, se incluyen Cloud Storage, Firestore, Cloud SQL, Pub/Sub y Cloud Tasks. Esta página está destinada a administradores, operadores o desarrolladores que administran políticas de la organización y el acceso de usuarios, o a cualquier persona que desee aprender sobre estos temas.

Identidades de Cloud Run

Para usar Cloud Run, Google Cloud se requieren dos tipos de identidades con los permisos adecuados:

  • Cuenta de implementador de Cloud Run: Es la identidad (ya sea una cuenta de usuario o una cuenta de servicio) que usas para implementar y administrar un recurso de Cloud Run mediante el envío de solicitudes a la API de Cloud Run Admin.
  • Identidad del servicio de Cloud Run: Es la identidad (una cuenta de servicio) que usa la instancia de Cloud Run. Cuando el código de Cloud Run que escribiste interactúa con las bibliotecas cliente de Cloud o llama a otro servicio de Cloud Run para la comunicación de servicio a servicio, usas esta identidad para realizar solicitudes de Cloud Run a Google Cloud las APIs o a otros servicios de Cloud Run.

Para acceder y realizar solicitudes a las Google Cloud APIs o comunicarse entre servicios, cada identidad debe tener los permisos adecuados otorgados a ellas en Identity and Access Management (IAM).

Llama a la API de Cloud Run Admin con la cuenta de implementador

Llamas a la API de Cloud Run Admin desde Cloud Run con la cuenta de implementador de Cloud Run. La cuenta de implementador puede ser de usuario o una cuenta de servicio y representa la cuenta que se firmó en el Google Cloud entorno.

Cuando la cuenta de implementador usa Cloud Run, IAM verifica si la cuenta de implementador tiene los permisos necesarios para realizar de Cloud Run. En el siguiente diagrama, se muestra cómo un usuario llama a la API de Cloud Run Admin para implementar una revisión nueva desde la Google Cloud consola:

Llama a la API de Cloud Run Admin desde la consola de Google Cloud .
Figura 1. Un usuario usa la Google Cloud consola para implementar una revisión a través del envío de una solicitud con un token de acceso al API de Cloud Run Admin. IAM usa ese token de acceso para verificar que la cuenta de usuario esté autenticada para acceder a la API de Cloud Run Admin antes de realizar la operación.

Llama a las Google Cloud APIs con la identidad de servicio

Cuando una instancia de Cloud Run interactúa con otros servicios de Cloud Run autenticados por IAM o llama a las bibliotecas cliente de Cloud a través del código de la aplicación o funciones integradas como integraciones de Cloud Run o activaciones de volumen de Cloud Storage, el Google Cloud entorno usa credenciales predeterminadas de la aplicación (ADC) para detectar de forma automática si la identidad del servicio de Cloud Run se autentica para realizar la operación de la API. Cloud Run Service Identity es una cuenta de servicio que se asignó como la identidad de tu instancia de Cloud Run cuando implementas una revisión o ejecutar un trabajo.

Una cuenta de servicio que se use como cuenta de implementador solo se usará la identidad de servicio si configuras la misma cuenta de servicio en tu Configuración de Cloud Run.

En el resto de esta guía, se describe cómo se usa un recurso de Cloud Run usa la identidad de servicio para llamar y acceder a servicios de Google y APIs. Para más información sobre la configuración de identidad del servicio, consulta la documentación identidad del servicio páginas de configuración de servicios, trabajos, y grupos de trabajadores.

Tipos de cuentas de servicio para la identidad de servicio

Cuando tu instancia de Cloud Run realiza llamadas a Google Cloud las APIs para realizar las operaciones que necesita, Cloud Run usa automáticamente una cuenta de servicio como la identidad de servicio. Los dos tipos de cuentas de servicio que se pueden usar como identidad de servicio son las siguientes:

  • Cuenta de servicio administrada por el usuario (opción recomendada): Debes crearla manualmente. esta cuenta de servicio y determinar el conjunto de permisos más mínimo que la cuenta de servicio necesita para acceder a recursos específicos Google Cloud . El cuenta de servicio administrada por el usuario sigue el formato SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com.
  • Cuenta de servicio predeterminada de Compute Engine: Cloud Run proporciona automáticamente la cuenta de servicio predeterminada de Compute Engine la identidad predeterminada del servicio. La cuenta de servicio predeterminada de Compute Engine el formato de PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Evita la cuenta de servicio predeterminada cuando configures la identidad de servicio

De forma predeterminada, la cuenta de servicio predeterminada de Compute Engine de crear. Si no especificas una cuenta de servicio cuando se crea un recurso de Cloud Run, Cloud Run usa esta cuenta de servicio.

Según la configuración de la política de la organización, es posible que a la cuenta de servicio predeterminada se le otorgue automáticamente el rol de editor en tu proyecto. Te recomendamos inhabilitar la concesión automática de roles; para ello, aplica la restricción de la política de la organización iam.automaticIamGrantsForDefaultServiceAccounts. Si creaste tu organización después del 3 de mayo de 2024, esta restricción se aplica de forma predeterminada.

Si inhabilitas la concesión automática de roles, debes decidir qué roles se deben otorgar a las cuentas de servicio predeterminadas y, luego, otorgar estos roles a ti mismo.

Si la cuenta de servicio predeterminada ya tiene el rol de editor, te recomendamos que reemplaces el rol de editor por roles menos permisivos.Para modificar de forma segura los roles de la cuenta de servicio, usa Policy Simulator para ver el impacto de los cambios y, luego, otorga y revoca los roles adecuados.

Cómo funciona la identidad de servicio

Cuando tu código usa bibliotecas cliente de Cloud que realizan solicitudes a Google Cloud API, sucede lo siguiente:

  1. La biblioteca cliente solicita un token de acceso de OAuth 2.0 para la identidad del servicio desde el servidor de metadatos de la instancia.
  2. El servidor de metadatos de la instancia proporciona un token de acceso de IAM la cuenta de servicio configurada como la identidad de servicio.
  3. Se envía la solicitud a la Google Cloud API con un token de acceso de OAuth 2.0.
  4. IAM verifica la identidad del servicio a la que se hace referencia en el token de acceso para los permisos necesarios y verifica las vinculaciones de políticas antes de reenviar la llamada al extremo de API.
  5. La Google Cloud API realiza la operación.
Llama a la API de Google Cloud desde Cloud Run.
Figura 1. Cloud Run genera un token de acceso desde el servidor de metadatos, e IAM lo usa para verificar que la identidad del servicio de Cloud Run asignada se autentique para acceder a las Google Cloud APIs.

Genera un token de acceso para la solicitud de Cloud Run para llamar a las Google Cloud APIs

Si tu código de Cloud Run usa Bibliotecas cliente de Cloud, configuras servicios Identity en Cloud Run asignando una cuenta de servicio en la implementación o la ejecución. Esto permite que la biblioteca adquiera acceso token para autenticar la solicitud de tu código. Si tu código de Cloud Run se comunica con otros servicios autenticados de Cloud Run, debes agregar el token de acceso a tus solicitudes.

Para asignar una cuenta de servicio como identidad del servicio, consulta las siguientes guías:

Sin embargo, si usas tu propio código personalizado o necesitas realizar solicitudes de manera programática, puedes usar el servidor de metadatos directamente para recuperar manualmente los tokens de identidad y los tokens de acceso que se describen en la próxima sección. Ten en cuenta que no puedes consultar este servidor directamente desde tu máquina local, ya que el servidor de metadatos solo está disponible para las cargas de trabajo que se ejecutan en Google Cloud.

Recupera los tokens de ID y acceso con el servidor de metadatos

Los dos tipos de tokens que puedes recuperar con el servidor de metadatos son los siguientes:

  • Tokens de acceso de OAuth 2.0, que se usan para llamar a la mayoría de las bibliotecas cliente de las APIs de Google.
  • Tokens de ID, que se usan para llamar a otros servicios de Cloud Run o para invocar cualquier servicio para validar un token de ID.

Para recuperar un token, sigue las instrucciones en la pestaña correspondiente para el tipo de token que usas:

Tokens de acceso

Por ejemplo, si deseas crear un tema de Pub/Sub, usa el método projects.topics.create.

  1. Usa el servidor de metadatos de Compute para recuperar un token de acceso:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
        --header "Metadata-Flavor: Google"

    Este extremo muestra una respuesta JSON con un atributo access_token.

  2. En tu solicitud de protocolo HTTP, la solicitud debe autenticarse con un token de acceso en el encabezado Authorization:

    PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
    Authorization: Bearer ACCESS_TOKEN
    

    Donde:

    • PROJECT_ID es el ID del proyecto.
    • TOPIC_ID es el ID del tema.
    • ACCESS_TOKEN es el token de acceso que recuperaste en el paso anterior.

    Respuesta:

    {
        "name": "projects/PROJECT_ID/topics/TOPIC_ID"
    }
    

Tokens de ID

Usa el servidor de metadatos de Compute para recuperar un token de identidad con un público específico:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
    --header "Metadata-Flavor: Google"

En el ejemplo anterior, AUDIENCE es el JWT Audience solicitado.

Para los servicios de Cloud Run, el público debe ser la URL del servicio que invocas o un público personalizado, como un dominio personalizado, configurado para el servicio.

https://service.domain.com

Para otros recursos, es probable que sea el ID de cliente de OAuth de un recurso protegido por IAP:

1234567890.apps.googleusercontent.com

Próximos pasos