Prepárate para los próximos cambios de autorización

Application Integration está actualizando la forma en que se autorizan las integraciones. Estos cambios entrarán en vigencia pronto. La mayoría de las integraciones seguirán ejecutándose sin cambios, mientras que algunas integraciones requieren un cambio de configuración para continuar ejecutándose. Todo lo que se describe en esta página usa una configuración que ya controlas, por lo que puedes realizar estos cambios ahora.

Próximos cambios de autorización

Application Integration está actualizando la forma en que controla las identidades para las ejecuciones de integración. Cada ejecución ahora debe tener una identidad explícita, que actúe como una de las siguientes:

• El usuario que activó la ejecución. Los sistemas llamados aplican los permisos de acceso de ese usuario.
• Una cuenta de servicio de ejecución. Controlas, defines el alcance y auditas esta cuenta como cualquier otra cuenta de servicio en tu proyecto de Google Cloud.

Debido a esta actualización, sucede lo siguiente:

• Para ejecutar una integración, necesitas permiso para actuar como la cuenta de servicio de ejecución.
• Si ninguna de las identidades está disponible, falla la ejecución de la integración.

Antes de comenzar

Completa las siguientes tareas en orden. Haz la primera primero, porque las otras dos terminan en una publicación, y la publicación en sí se verifica con permisos.

1. Otorga el rol Usuario de cuenta de servicio en cada cuenta de servicio de ejecución que ya uses a todos los que ejecuten, aprueben, editen o publiquen la integración, incluidas las cuentas de servicio que usa tu automatización.
2. Establece una cuenta de servicio de ejecución en las integraciones que se ejecutan sin una persona y no tienen una.
3. Otorga el rol Usuario de cuenta de servicio en la cuenta de servicio que se nombra en cada perfil de autenticación de tipo Cuenta de servicio o Token de OIDC. Por lo general, estas son cuentas diferentes de tu cuenta de servicio de ejecución.

Advertencia: Completa la tarea 1 antes de las tareas 2 y 3. Establecer o cambiar una cuenta de servicio de ejecución significa publicar la integración, y la publicación requiere el mismo permiso. Si estableces la cuenta de servicio primero, se puede rechazar la publicación que habría guardado tu corrección.

Integraciones que requieren una cuenta de servicio de ejecución

Determina si una integración necesita una

Solo necesitas una cuenta de servicio de ejecución cuando las credenciales de nadie están disponibles para toda la ejecución. Eso sucede en dos situaciones, y solo en dos:

Cómo se ejecuta la integración	¿Las credenciales de alguien están disponibles?	¿Necesita una cuenta de servicio de ejecución?
De forma síncrona : Alguien la inicia y espera el resultado.	Sí, para toda la ejecución.	No
De forma asíncrona : Se pone en cola y finaliza más tarde.	Solo en el momento en que se activa.	Sí
Sin supervisión : Un programa o un evento la inicia.	No, nunca hay una persona.	Sí

Nota: Las ejecuciones asíncronas se cuentan incluso si una persona las activó: el trabajo en cola no lleva las credenciales de esa persona, por lo que, cuando se ejecuta, no queda nadie para autorizarlo. Una integración que solo se ejecuta de forma síncrona ya tiene una identidad y no necesita ningún cambio.

Identifica las integraciones afectadas

Primero, ¿alguna vez se ejecuta sin una persona? Lo hace si se cumple alguna de las siguientes condiciones:

• Tiene un activador de eventos de Cloud Scheduler, Cloud Pub/Sub, Salesforce, o Integration Connectors event trigger.
• Algo lo programa a través de la API con scheduleIntegrations.
• Otra integración la llama como una subintegración asíncrona, mediante la tarea Integración de llamadas.
• Usa la tarea Suspender o Aprobar, en la que una ejecución puede esperar y, luego, vencer por sí sola.

En segundo lugar, ¿su cuenta de servicio de ejecución está vacía? Para enumerar cada versión publicada en una región junto con su cuenta de servicio de ejecución, ejecuta el siguiente comando:

curl -s -G -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-urlencode "filter=state=ACTIVE" \
  --data-urlencode "pageSize=1000" \
  "https://REGION-integrations.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/integrations/-/versions" \
| jq -r '.integrationVersions[]
         | [ .name, (.runAsServiceAccount // "NONE") ]
         | @tsv'

Reemplaza lo siguiente:

• REGION: Es la región de tu integración. Para obtener la lista de las regiones compatibles, consulta Ubicaciones.
• PROJECT_ID: Es el ID de tu proyecto de Google Cloud.

• Una fila que muestra NONE solo necesita acción si la primera mitad también se aplica a ella también.
• Para verificar una sola integración, ábrela en la Google Cloud consola y consulta el Resumen de la integración panel en la barra de herramientas de integración.

Precaución: Mantén filter=state=ACTIVE en la solicitud en lugar de filtrar el resultado después. El comodín - muestra una versión por integración (la modificada más recientemente), por lo que, si recuperas todo y filtras más tarde, cualquier integración cuya versión más reciente sea un borrador no publicado se quitará de los resultados, incluso cuando tenga una versión publicada que aún se esté ejecutando. Si la respuesta contiene un nextPageToken, repite la solicitud con pageToken=TOKEN hasta que el token deje de regresar.

Actualiza tus integraciones

Otorga el rol Usuario de cuenta de servicio

Para otorgar el rol a alguien, ejecuta el siguiente comando:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT \
    --project=SERVICE_ACCOUNT_PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/iam.serviceAccountUser'

Reemplaza lo siguiente:

• SERVICE_ACCOUNT: Es la dirección de correo electrónico de la cuenta de servicio de ejecución o de la cuenta que se nombra en un perfil de autenticación.
• SERVICE_ACCOUNT_PROJECT_ID: Es el ID del proyecto que posee la cuenta de servicio.
• PRINCIPAL: Es la dirección de correo electrónico del usuario.

Para otros tipos principales, usa el prefijo --member correspondiente:

• Grupos: Usa group:. Recomendamos usar Grupos de Google en lugar de cuentas de usuario individuales para simplificar la administración de acceso a medida que cambian los miembros del equipo.
• Cuentas de servicio: Usa serviceAccount: para procesos automatizados y aplicaciones.

Precaución: La marca --project debe nombrar el proyecto que posee la cuenta de servicio. Si tu cuenta de servicio de ejecución reside en un proyecto diferente al de la integración, la concesión pertenece al proyecto de la cuenta de servicio. Si la otorgas en el proyecto de la integración, no sucederá nada. Este es el el error más común cuando se realiza este cambio.

Para hacer lo mismo en la Google Cloud consola, sigue estos pasos:

1. Ve a IAM y administración > Cuentas de servicio.
2. Selecciona la cuenta de servicio.
3. Haz clic en Permisos > Otorgar acceso.

Para obtener más información, consulta Administra el acceso a las cuentas de servicio.

Establece una cuenta de servicio de ejecución

1. Elige o crea la cuenta de servicio y otórgale los roles que necesitan las tareas de la integración en los recursos que tocan. Para determinar qué otorgar, consulta los roles que tiene hoy el agente de servicio de Application Integration de tu proyecto, service-PROJECT_NUMBER@gcp-sa-integrations., y otorga a la cuenta nueva solo la parte que usa esta integración.
2. Otorga el rol Usuario de cuenta de servicio a todos los que ejecuten, aprueben, editen o publiquen la integración, incluida cualquier automatización.
3. Abre la integración y establece la cuenta de servicio en el Resumen de la integración panel en el barra de herramientas de integración.
4. Publica la integración. Para obtener más información, consulta Prueba y publica integraciones.

Google Cloud recomienda usar una cuenta de servicio dedicada y con un alcance mínimo para cada integración en lugar de una cuenta con privilegios amplios compartida en todas ellas, ya que hace lo siguiente:

• Contiene el efecto de cualquier integración.
• Aparece por nombre en tus registros de auditoría.

Para obtener más información, consulta Prácticas recomendadas para trabajar con cuentas de servicio.

Soluciona problemas de permisos faltantes

Una acción denegada tiene una de dos causas, y vale la pena distinguirlas:

• La cuenta de servicio de ejecución : No puedes actuar como ella o no puede alcanzar lo que necesita una tarea.
• Tu propio rol de IAM : No tienes permiso para realizar la acción en absoluto.

Ambas verificaciones se aplican, por lo que corregir una no corrige la otra.

Errores de la cuenta de servicio de ejecución

Situación	Lo que verá:	Qué hacer
Alguien activa una integración, pero no puede actuar como su cuenta de servicio de ejecución	Se rechaza el activador con PERMISSION_DENIED. La verificación se ejecuta antes de que se ponga en cola la ejecución, por lo que no aparece nada en tus registros de ejecución. Parece que no sucedió nada, en lugar de que falló una tarea.	Otorga el rol Usuario de cuenta de servicio a quien lo active.
Una ejecución sin credenciales de usuario no tiene una cuenta de servicio de ejecución.	Las tareas de Connectors, Llamar a extremo de REST y Cloud Run Functions fallan en lo que intentan alcanzar. En la publicación: The integration is missing run-as service account since governance is enabled for your project.	Establece una cuenta de servicio de ejecución.
Una tarea usa un perfil de autenticación cuya cuenta de servicio no puede actuar como el llamador.	Se deniega esa tarea mientras el resto de la ejecución continúa: You do not have permission to use Auth Config ID because you cannot act as its service account: SERVICE_ACCOUNT.	Otorga el rol Usuario de cuenta de servicio en la cuenta que se nombra en el perfil.
Un aprobador no puede actuar como la cuenta de servicio de ejecución.	El proceso de aprobación falla de forma silenciosa sin generar un error visible. La ejecución permanece en pausa hasta que vence, por lo que lo que notas es que las aprobaciones parecen haber dejado de funcionar.	Otorga el rol Usuario de cuenta de servicio a todos los que puedan aprobar.
Alguien edita o publica una integración sin el permiso.	Publisher does not have required permission to publish integration with service account: SERVICE_ACCOUNT. Todo lo que ya se publicó sigue ejecutándose. Si la automatización publica por ti, esto aparece en tu canalización de implementación en lugar de en la consola.	Otorga el rol Usuario de cuenta de servicio a editores, publicadores, y automatización
Una tarea se ejecuta como la persona que la activó, y esa persona no puede acceder al recurso	La ejecución comienza con normalidad y, luego, una tarea falla y nombra un recurso, aunque no cambió nada sobre la integración.	Otorga a esas personas acceso al recurso o mueve la integración a una cuenta de servicio de ejecución que ya lo tenga. Por lo general, esta es la mejor respuesta, ya que detiene el acceso de la integración que varía con quien la ejecuta.

Para obtener la lista completa de códigos de error de Application Integration, consulta Códigos de error.

Advertencia: Verifica de forma proactiva tus integraciones programadas y basadas en eventos. Debido a que estas integraciones se ejecutan automáticamente, las fallas no activan advertencias de la consola y, si la programación es poco frecuente, es posible que la integración no se ejecute en absoluto antes de que el cambio entre en vigencia.

Errores de roles de IAM

Además de la cuenta de servicio de ejecución, Application Integration verifica tus permisos de IAM de usuario para cada acción. Si encuentras un PERMISSION_DENIED error cuando interactúas con una integración o si no se cargan los registros de ejecución, asegúrate de tener un rol que otorgue los permisos necesarios:

Para hacer esto	Necesitas uno de estos roles
Ver y abrir integraciones	roles/integrations.integrationViewer
Ver registros y detalles de ejecución	roles/integrations.integrationViewer o roles/integrations.integrationInvoker
Ejecutar una integración	roles/integrations.integrationInvoker o roles/integrations.integrationEditor
Crear y editar integraciones	roles/integrations.integrationEditor
Publicar una integración	roles/integrations.integrationDeployer o roles/integrations.integrationEditor
Aprobar o reanudar una ejecución suspendida	roles/integrations.suspensionResolver o roles/integrations.integrationAdmin
Acceso completo a todas las integraciones	roles/integrations.integrationAdmin

Nota: Para aprobar o reanudar una ejecución suspendida, se requiere el integrations.suspensions.resolve permiso, que no incluye el roles/integrations.integrationEditor rol. Los aprobadores requieren el rol roles/integrations.suspensionResolver, así como el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la cuenta de servicio de ejecución.

Nota: Ninguno de estos roles te permite cambiar quién tiene acceso. Para otorgar los roles y permisos que se describen en esta página, se necesita un rol independiente:

• roles/iam.serviceAccountAdmin para otorgar el rol Usuario de cuenta de servicio en una cuenta de servicio.
• roles/resourcemanager.projectIamAdmin para otorgar roles de Application Integration a nivel de proyecto.

Los propietarios del proyecto tienen ambos. Si no puedes otorgar un permiso por tu cuenta, pídele a un administrador que lo haga.

Para otorgar un rol, ejecuta el siguiente comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='ROLE'

Para obtener más información, consulta lo siguiente:

• Roles predefinidos de IAM, para obtener la lista completa de roles y los permisos que contiene cada uno.
• Control de acceso, para saber cómo Application Integration usa IAM.

Precaución: Si tu organización define el alcance de los roles para integraciones individuales con las condiciones de IAM, la condición debe coincidir con la integración específica a la que accedes. Una vinculación de roles que otorga acceso a una integración puede denegar el acceso a otra. Si encuentras errores de permisos a pesar de tener el rol correcto, verifica las condiciones adjuntas a tu vinculación de roles.

Preguntas frecuentes

Otorgué el rol y aún falla. ¿Qué me falta?

• La concesión fue al proyecto incorrecto. Se debe realizar en el proyecto que posee la cuenta de servicio, que no es necesariamente el que posee la integración.
• Aún no entró en vigencia. Dale unos minutos. Las decisiones de autorización se almacenan en caché brevemente, además de la demora de propagación normal de IAM.
• Hay una segunda cuenta de servicio involucrada. Tu cuenta de servicio de ejecución y la cuenta de servicio de cada perfil de autenticación están separadas, y ambas necesitan la concesión.
• El bloqueo es tu propio rol, no la cuenta de servicio. El rol Usuario de cuenta de servicio se trata de si puedes actuar como la cuenta de servicio de ejecución; un rol de IAM independiente rige si tienes permiso para realizar la acción. Consulta Errores de roles de IAM.

¿Por qué ya no es suficiente el rol Invocador de integración?

Aún te permite ejecutar la integración. Lo que nunca hizo es permitirte actuar como la cuenta de servicio que ejecuta la integración, y eso es lo que decide cuánto acceso obtiene la ejecución. Ninguno de los siguientes roles otorga iam.serviceAccounts.actAs, por lo que siempre es una concesión independiente:

• roles/integrations.integrationAdmin
• roles/integrations.integrationEditor
• roles/integrations.integrationInvoker

Mi integración solo se ejecuta de forma síncrona. ¿Necesito una cuenta de servicio de ejecución?

No. Una ejecución síncrona ya tiene una identidad: la persona que la activó. Consulta Determina si una integración necesita una.

No se marcó nada en la consola. ¿Estoy bien?

No necesariamente. Las advertencias dependen en parte de las ejecuciones observadas, por lo que una integración en un programa poco frecuente o una que nadie haya activado recientemente puede necesitar acción sin mostrarte una advertencia. Trabaja con Integraciones que requieren una cuenta de servicio de ejecución en lugar de leer una consola silenciosa como un todo claro.

¿Qué sigue?

• Lee los lineamientos de seguridad de Application Integration.
• Revisa los roles predefinidos de IAM para Application Integration.
• Obtén información para configurar perfiles de autenticación.
• Lee las prácticas recomendadas para trabajar con cuentas de servicio.