Si tu arquitectura usa varios servicios, es probable que estos servicios tengan que comunicarse entre sí mediante métodos asíncronos o síncronos. Muchos de estos servicios pueden ser privados y, por lo tanto, requieren credenciales para acceder.
Para la comunicación asíncrona, puedes usar los siguientes servicios: Google Cloud
- Cloud Tasks para la comunicación asíncrona individual
- Pub/Sub para la comunicación asíncrona de uno a muchos, de uno a uno y de muchos a uno
- Cloud Scheduler para la comunicación asíncrona programada periódicamente
- Eventarc para la comunicación basada en eventos
En todos estos casos, el servicio utilizado gestiona la interacción con el servicio receptor en función de la configuración que hayas definido.
Sin embargo, en la comunicación síncrona, tu servicio llama a otro servicio directamente a través de HTTP mediante su URL de endpoint. En este caso práctico, debes asegurarte de que cada servicio solo pueda enviar solicitudes a servicios específicos. Por ejemplo, si tienes un servicio login
, debería poder acceder al servicio user-profiles
, pero no al servicio search
.
En esta situación, Google recomienda que uses IAM y una identidad de servicio basada en una cuenta de servicio gestionada por el usuario por servicio a la que se le haya concedido el conjunto mínimo de permisos necesarios para hacer su trabajo.
Además, la solicitud debe presentar una prueba de la identidad del servicio que llama. Para ello, configura tu servicio de llamadas para que añada un token de ID de OpenID Connect firmado por Google como parte de la solicitud.
Configurar la cuenta de servicio
.Para configurar una cuenta de servicio, debes configurar el servicio receptor para que acepte solicitudes del servicio llamante. Para ello, convierte la cuenta de servicio del servicio llamante en un principal en el servicio receptor. A continuación, asigna a esa cuenta de servicio el rol Invocador de Cloud Run (roles/run.invoker
). Para llevar a cabo ambas tareas, sigue las instrucciones de la pestaña correspondiente:
Interfaz de usuario de la consola
Ve a la Google Cloud consola:
Selecciona el servicio receptor.
Haz clic en Mostrar panel de información en la esquina superior derecha para ver la pestaña Permisos.
Haz clic en Añadir principal.
Introduce la identidad del servicio que llama. Normalmente, se trata de una dirección de correo electrónico. De forma predeterminada, es
PROJECT_NUMBER-compute@developer.gserviceaccount.com
.Selecciona el rol
Cloud Run Invoker
en el menú desplegable Selecciona un rol.Haz clic en Guardar.
gcloud
Usa el comando gcloud run services add-iam-policy-binding
:
gcloud run services add-iam-policy-binding RECEIVING_SERVICE \ --member='serviceAccount:CALLING_SERVICE_IDENTITY' \ --role='roles/run.invoker'
donde RECEIVING_SERVICE
es el nombre del servicio receptor y CALLING_SERVICE_IDENTITY
es la dirección de correo de la cuenta de servicio, que es PROJECT_NUMBER-compute@developer.gserviceaccount.com
de forma predeterminada.
Terraform
Para saber cómo aplicar o quitar una configuración de Terraform, consulta Comandos básicos de Terraform.
Añade lo siguiente a un recursogoogle_cloud_run_v2_service
en tu configuración de Terraform:Sustituye us-docker.pkg.dev/cloudrun/container/hello
por una referencia a tu imagen de contenedor.
El siguiente código de Terraform hace que el servicio inicial sea público.
El siguiente código de Terraform crea un segundo servicio de Cloud Run que está diseñado para ser privado.
Sustituye us-docker.pkg.dev/cloudrun/container/hello
por una referencia a tu imagen de contenedor.
El siguiente código de Terraform hace que el segundo servicio sea privado.
El siguiente código de Terraform crea una cuenta de servicio.
El siguiente código de Terraform permite que los servicios vinculados a la cuenta de servicio invoquen el servicio de Cloud Run privado inicial.
Obtener y configurar el token de ID
Después de asignar el rol adecuado a la cuenta de servicio que hace la llamada, sigue estos pasos:
Obtén un token de ID firmado por Google mediante uno de los métodos descritos en la siguiente sección. Define la reclamación de audiencia (
aud
) en la URL del servicio receptor o en una audiencia personalizada configurada. Si no utiliza una audiencia personalizada, el valor deaud
debe seguir siendo la URL del servicio, incluso cuando se hagan solicitudes a una etiqueta de tráfico específica.Añade el token de ID que has obtenido en el paso anterior a uno de los siguientes encabezados de la solicitud al servicio receptor:
- Un encabezado
Authorization: Bearer ID_TOKEN
. - Un encabezado
X-Serverless-Authorization: Bearer ID_TOKEN
. Puedes usar este encabezado si tu aplicación ya usa el encabezadoAuthorization
para la autorización personalizada. De esta forma, se elimina la firma antes de pasar el token al contenedor del usuario.
- Un encabezado
Para ver otras formas de obtener un token de ID que no se describen en esta página, consulta Métodos para obtener un token de ID.
Usar las bibliotecas de autenticación
Una forma de obtener y configurar el proceso del token de ID es usar las bibliotecas de autenticación.
Este código funciona en cualquier entorno, incluso fuera de Google Cloud, donde las bibliotecas pueden obtener credenciales de autenticación para una cuenta de servicio. Para usar este método, descarga un archivo de clave de cuenta de servicio y define la variable de entorno GOOGLE_APPLICATION_CREDENTIALS
en la ruta del archivo de clave de cuenta de servicio. Para obtener más información, consulta el artículo sobre las claves de cuentas de servicio.
Este código no acepta credenciales de autenticación para una cuenta de usuario.
Node.js
Python
Go
Java
Usar el servidor de metadatos
Si por algún motivo no puedes usar las bibliotecas de autenticación, puedes obtener un token de ID del servidor de metadatos de Compute mientras tu contenedor se ejecuta en Cloud Run. Ten en cuenta que este método no funciona fuera de Google Cloud, ni siquiera desde tu máquina local.
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]" \
-H "Metadata-Flavor: Google"
Donde AUDIENCE es la URL del servicio que estás invocando o una audiencia personalizada configurada.
En la siguiente tabla se resumen las partes principales de una solicitud de consulta de metadatos:
Componentes | Descripción |
---|---|
URL raíz | Todos los valores de metadatos se definen como subrutas de la siguiente URL raíz: http://metadata.google.internal/computeMetadata/v1 |
Encabezado de solicitud | El siguiente encabezado debe estar en cada solicitud: Metadata-Flavor: Google Este encabezado indica que la solicitud se ha enviado para recuperar valores de metadatos y que no proviene de una fuente no segura desde la que se ha enviado involuntariamente. Además, permite que el servidor de metadatos devuelva los datos que has solicitado. Si no proporcionas este encabezado, el servidor de metadatos denegará tu solicitud. |
Para ver un tutorial completo sobre una aplicación que usa esta técnica de autenticación entre servicios, consulta el tutorial sobre cómo proteger servicios de Cloud Run.
Usar la federación de identidades de cargas de trabajo desde fuera Google Cloud
Si tu entorno usa un proveedor de identidades compatible con la federación de identidades de cargas de trabajo, puedes usar el siguiente método para autenticarte de forma segura en tu servicio de Cloud Run desde fuera de Google Cloud:
Configura tu cuenta de servicio tal como se describe en la sección Configurar la cuenta de servicio de esta página.
Configura la federación de identidades de cargas de trabajo para tu proveedor de identidades tal como se describe en el artículo Configurar la federación de identidades de cargas de trabajo.
Sigue las instrucciones que se indican en el artículo Conceder permiso a identidades externas para suplantar la identidad de una cuenta de servicio.
Usa la API REST para obtener un token de corta duración, pero, en lugar de llamar a
generateAccessToken
para obtener un token de acceso, llama agenerateIdToken
para obtener un token de ID.Por ejemplo, con cURL:
ID_TOKEN=$(curl -0 -X POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT:generateIdToken \ -H "Content-Type: text/json; charset=utf-8" \ -H "Authorization: Bearer $STS_TOKEN" \ -d @- <<EOF | jq -r .token { "audience": "SERVICE_URL" } EOF ) echo $ID_TOKEN
Donde
SERVICE_ACCOUNT
es la dirección de correo de la cuenta de servicio a la que se ha configurado el grupo de identidades de carga de trabajo para acceder ySERVICE_URL
es la URL del servicio de Cloud Run que estás invocando. Este valor debe seguir siendo la URL del servicio, incluso cuando se hagan solicitudes a una etiqueta de tráfico específica.$STS_TOKEN
es el token del servicio de tokens de seguridad que has recibido en el paso anterior de las instrucciones de federación de identidades de carga de trabajo.
Puedes incluir el token de ID del paso anterior en la solicitud al servicio mediante un encabezado Authorization: Bearer ID_TOKEN
o un encabezado X-Serverless-Authorization: Bearer ID_TOKEN
. Si se proporcionan ambos encabezados, solo se comprueba el encabezado X-Serverless-Authorization
.
Usar una clave de cuenta de servicio descargada desde fuera Google Cloud
Si la federación de identidades de carga de trabajo no es adecuada para tu entorno, puedes usar una clave de cuenta de servicio descargada para autenticarte desde fuera deGoogle Cloud. Actualiza el código de tu cliente para usar las bibliotecas de autenticación tal como se ha descrito anteriormente. Para obtener más información, consulta el artículo sobre las claves de cuentas de servicio.
Puedes obtener un token de ID firmado por Google mediante un JWT autofirmado, pero este proceso es bastante complicado y puede dar lugar a errores. Los pasos básicos son los siguientes:
Autofirma un JWT de cuenta de servicio con la reclamación
target_audience
definida en la URL del servicio receptor o en una audiencia personalizada configurada. Si no se usan dominios personalizados, el valor detarget_audience
debe seguir siendo la URL del servicio, incluso cuando se hagan solicitudes a una etiqueta de tráfico específica.Intercambia el JWT autofirmado por un token de ID firmado por Google, que debe tener la reclamación
aud
definida en la URL anterior.Incluye el token de ID en la solicitud al servicio mediante un encabezado
Authorization: Bearer ID_TOKEN
o un encabezadoX-Serverless-Authorization: Bearer ID_TOKEN
. Si se proporcionan ambas cabeceras, solo se comprueba la cabeceraX-Serverless-Authorization
.
Recibir solicitudes autenticadas
En el servicio privado receptor, puedes analizar el encabezado de autorización para recibir la información que envía el token de portador.