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 APIs de Google Cloud. Entre los ejemplos de productos de Google Cloud 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 organizaciones 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 requiere que el usuario de Cloud Run y la instancia de Cloud Run tengan una identidad.

  • La identidad del usuario de Cloud Run se conoce como Cuenta de implementador de Cloud Run. Cuando administras una revisión o un trabajo, usas esta identidad para realizar solicitudes a la API de Cloud Run Admin.
  • La identidad de la instancia de Cloud Run se conoce como Identidad del servicio 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 las APIs de Google Cloud o a otros servicios de Cloud Run.

Para acceder y realizar solicitudes a las APIs de Google Cloud 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

Puedes llamar a la API de Cloud Run Admin desde Cloud Run con el comando 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 entorno de Google Cloud.

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 el Consola de Google Cloud:

Llama a la API de Cloud Run Admin desde la consola de Google Cloud.
Figura 1. Un usuario usa la consola de Google Cloud para implementar un 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 APIs de Google Cloud 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 las integraciones de Cloud Run o activaciones de volumen de Cloud Storage, el entorno de Google Cloud 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 servicio o un trabajo usa la identidad de servicio para llamar y acceder a servicios de Google y APIs. Para más información más información sobre la configuración de identidad del servicio, consulta la documentación páginas de configuración de servicios y jobs.

Tipos de cuentas de servicio para la identidad de servicio

Cuando tu instancia de Cloud Run realiza llamadas a las APIs de Google Cloud 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. la cuenta de servicio y determinar el conjunto de permisos más mínimo necesita acceder a recursos específicos de 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 trabajo o servicio 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 del cambio y, luego, otorga y revoca los roles adecuados.

Cómo funciona la identidad de servicio

Cuando tu código llama o realiza solicitudes a las bibliotecas cliente de Cloud, sucede lo siguiente: ocurre:

  1. Las bibliotecas cliente detectan que se realiza una solicitud a un bucket de API o para las bibliotecas cliente de Cloud y solicita un token de acceso de OAuth 2.0 para el 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 API de Google Cloud con un token de acceso de OAuth 2.0.
  4. IAM verifica la identidad del servicio a la que se hace referencia en las token para los permisos necesarios y verifica las vinculaciones de políticas antes de reenvía la llamada al extremo de la API.
  5. La API de Google Cloud 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 APIs de Google Cloud.

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

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 servidor de metadatos directamente para recuperar manualmente los tokens de identidad y de acceso que se describen en la 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 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:

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

    Aquí:

    • 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