Si en tu arquitectura usas varios servicios, es probable que estos deban comunicarse entre sí mediante medios asíncronos o síncronos. Es posible que muchos de estos servicios sean privados y requieran credenciales para el acceso.
Para la comunicación asíncrona, puedes usar los siguientes servicios de Google Cloud:
- Cloud Tasks para la comunicación asíncrona uno a uno
- Pub/Sub para una comunicación asíncrona uno a varios, uno a uno y varios a uno
- Cloud Scheduler para la comunicación asíncrona programada con regularidad
- Eventarc para la comunicación basada en eventos
En todos estos casos, el servicio que se usa administra la interacción con el servicio de recepción, en función de la configuración que estableciste.
Sin embargo, para la comunicación síncrona, tu servicio llama a otro servicio directamente, a través de HTTP, con su URL de extremo. Para este caso práctico, debes asegurarte de que cada servicio solo pueda realizar 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 administrada por el usuario de servicio a la que se le otorgó el conjunto mínimo de permisos necesarios para realizar su trabajo.
Además, la solicitud debe presentar un comprobante de la identidad del servicio de llamadas. Para ello, configura el servicio de llamadas a fin de que agregue un token de ID de OpenID Connect firmado por Google como parte de la solicitud.
Configura la cuenta de servicio
A fin de configurar una cuenta de servicio, configura el servicio de recepción para que acepte solicitudes del servicio de llamadas. Para ello, haz que la cuenta de servicio de llamada del miembro sea una principal en el servicio receptor. Luego, debes otorgar a esa cuenta de servicio la función de Invocador de Cloud Run (roles/run.invoker
). Para realizar ambas tareas, sigue las instrucciones en la pestaña correspondiente:
IU de Console
Ve a la consola de Google Cloud:
Selecciona el servicio de recepción.
Haz clic en Mostrar panel de información en la esquina superior derecha para que aparezca la pestaña Permisos.
Haz clic en Agregar principal.
Ingresa la identidad del servicio emisor. Por lo general, es una dirección de correo electrónico predeterminada
PROJECT_NUMBER-compute@developer.gserviceaccount.com
.Selecciona la función
Cloud Run Invoker
en el menú desplegable Selecciona una función.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 de recepción y CALLING_SERVICE_IDENTITY
es la dirección de correo electrónico de la cuenta de servicio, según la configuración predeterminada PROJECT_NUMBER-compute@developer.gserviceaccount.com
.
Terraform
Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform.
El siguiente código de Terraform crea un servicio inicial de Cloud Run diseñado para ser público.
Reemplaza 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 diseñado para ser privado.
Reemplaza 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.
Mediante el siguiente código de Terraform, se crea una cuenta de servicio.
El siguiente código de Terraform permite que los servicios adjuntos a la cuenta de servicio invoquen el servicio inicial privado de Cloud Run.
Adquiere y configura el token de ID
Después de otorgar el rol adecuado a la cuenta de servicio de llamadas, sigue estos pasos:
Recupera un token de ID firmado por Google mediante uno de los métodos descritos en la siguiente sección. Establece la reclamación del público (
aud
) en la URL del servicio receptor o en un público personalizado configurado. Si no usas un público personalizado, el valoraud
debe permanecer como la URL del servicio, incluso cuando se realizan solicitudes a una etiqueta de tráfico específica.Agrega el token de ID que recuperaste del paso anterior a uno de los siguientes encabezados en la solicitud al servicio de recepción:
- 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. Esto quita la firma antes de pasar el token al contenedor del usuario.
- Un encabezado
Si deseas conocer 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.
Usa las bibliotecas de autenticación
La forma más fácil y confiable de adquirir y configurar el proceso de token de ID
es usar las bibliotecas de autenticación.
Este código funciona en cualquier entorno, incluso fuera de Google Cloud, en el que las bibliotecas pueden obtener credenciales de autenticación para una cuenta de servicio, incluidos los entornos que admiten las credenciales predeterminadas de la aplicación locales.
Para configurar
las credenciales predeterminadas de la aplicación,
descarga un archivo de claves de la cuenta de servicio y
configura la variable de entorno GOOGLE_APPLICATION_CREDENTIALS
en la ruta del
archivo de claves de la cuenta de servicio. Para obtener más información, consulta
Cómo funcionan las credenciales predeterminadas de la aplicación.
Este código no funciona para obtener credenciales de autenticación para una cuenta de usuario.
Node.js
Python
Go
Java
Usa el servidor de metadatos
Si, por algún motivo, no puedes usar las bibliotecas de autenticación, puedes recuperar 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, incluso desde la 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 un público personalizado configurado.
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 la solicitud | El siguiente encabezado debe estar en cada solicitud: Metadata-Flavor: Google Este encabezado indica que la solicitud se envió con la intención de recuperar valores de metadatos, en lugar de hacerlo de forma involuntaria desde una fuente insegura, y permite que el servidor de metadatos muestre los datos que solicitaste. Si no proporcionas este encabezado, el servidor de metadatos rechaza tu solicitud. |
Para obtener una explicación completa de una aplicación que use esta técnica de autenticación de servicio a servicio, sigue el instructivo sobre cómo proteger los servicios de Cloud Run.
Usa la federación de Workload Identity desde fuera de Google Cloud
Si tu entorno usa un proveedor de identidad compatible con la federación de Workload Identity, puedes usar el siguiente método para autenticarte de forma segura en el servicio de Cloud Run desde fuera de Google Cloud:
Configura tu cuenta de servicio como se describe en Configura la cuenta de servicio en esta página.
Configura la federación de Workload Identity para tu proveedor de identidad como se describe en Configura la federación de Workload Identity.
Sigue las instrucciones en Otorga permisos a identidades externas para actuar en nombre de una cuenta de servicio.
Usa la API de REST para adquirir un token de corta duración, pero en lugar de llamar a
generateAccessToken
a fin de 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
SERVICE_ACCOUNT
es la dirección de correo electrónico de la cuenta de servicio a la que está configurado el grupo de identidades de carga de trabajo, ySERVICE_URL
es la URL del servicio de Cloud Run que invocas. Este valor debe seguir siendo la URL del servicio, incluso cuando se realizan solicitudes a una etiqueta de tráfico específica.$STS_TOKEN
es el token de servicio del token de seguridad que recibiste en el paso anterior en las instrucciones de federación de Workload Identity.
Puedes incluir el token de ID del paso anterior en la solicitud al
servicio mediante un encabezado Authorization: Bearer ID_TOKEN
o X-Serverless-Authorization: Bearer ID_TOKEN
. Si
se proporcionan ambos encabezados, solo se verifica
el encabezado X-Serverless-Authorization
.
Usa una clave de cuenta de servicio descargada desde fuera de Google Cloud
Si la federación de Workload Identity no es adecuada para tu entorno, puedes usar una clave de cuenta de servicio descargada a fin de autenticarte desde fuera de Google Cloud. Actualiza el código de cliente para usar las bibliotecas de autenticación como se describió anteriormente con las credenciales predeterminadas de la aplicación.
Puedes adquirir un token de ID firmado por Google con un JWT autofirmado, pero esto es bastante complicado y potencialmente propenso a errores. Los pasos básicos son los siguientes:
Autofirma un JWT de cuenta de servicio con la reclamación
target_audience
configurada como la URL del servicio receptor o un público personalizado configurado. Si no usas dominios personalizados, el valor detarget_audience
debe seguir siendo la URL del servicio, incluso cuando se realizan solicitudes a una etiqueta de tráfico específica.Intercambia el JWT autofirmado por un token de ID firmado por Google, que debería tener la reclamación
aud
configurada en la URL anterior.Incluye el token de ID en la solicitud al servicio mediante un encabezado
Authorization: Bearer ID_TOKEN
oX-Serverless-Authorization: Bearer ID_TOKEN
. Si se proporcionan ambos encabezados, solo se verifica el encabezadoX-Serverless-Authorization
.
Puedes examinar este ejemplo de funciones de Cloud Run para ver una muestra de los pasos anteriores.
Recibe solicitudes autenticadas
Dentro del servicio privado receptor, puedes analizar el encabezado de autorización para recibir la información que envía el token del portador.