Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Solicita permiso para conectar cuentas de servicio a los recursos

Cuando creas ciertos Google Cloud recursos, tienes la opción de conectar una cuenta de servicio. La cuenta de servicio conectada actúa como la identidad de cualquier trabajo que se ejecute en el recurso, lo que permite que los trabajos se autentiquen en las Google Cloud APIs.

En la mayoría de los Google Cloud servicios, los usuarios necesitan permiso para actuar en nombre de una cuenta de servicio a fin de conectarla a un recurso. Esto significa que el usuario necesita el permiso iam.serviceAccounts.actAs en la cuenta de servicio.

Sin embargo, en el pasado, algunos servicios permitían a los usuarios conectar cuentas de servicio a los recursos incluso si estos no tenían permiso para actuar en nombre de las cuentas de servicio. Esta configuración puede permitir que los usuarios de estos servicios obtengan permisos elevados y no evidentes.

En la siguiente tabla, se enumeran los servicios que tenían esta configuración, junto con el comportamiento heredado de cada servicio:

Servicio	Comportamiento heredado
App Engine	Los usuarios podrían implementar aplicaciones de App Engine, que usan la identidad de la cuenta de servicio predeterminada de App Engine, incluso si no tenían permiso para actuar en nombre de la identidad de la cuenta de servicio predeterminada de App Engine.
Managed Service para Apache Airflow	Los usuarios podían conectar cualquier cuenta de servicio del proyecto a un entorno de Managed Airflow, incluso si no tenían permiso para actuar en nombre de cualquiera de las cuentas de servicio del proyecto.
Cloud Data Fusion Dataflow Managed Service para Apache Spark	Los usuarios podían adjuntar la cuenta de servicio predeterminada de Compute Engine a los recursos, incluso si no tenían permiso para actuar en nombre de la cuenta de servicio predeterminada.
Dataform	Los usuarios podían conectar una cuenta de servicio a un recurso de Dataform y crear una invocación de flujo de trabajo que se ejecutaría como esa cuenta de servicio, incluso si no tenían permiso para actuar en nombre de la cuenta de servicio.

Ahora, es obligatorio que estos servicios verifiquen que los usuarios tengan permiso para actuar en nombre de las cuentas de servicio cuando se conectan las cuentas de servicio a los recursos. Sin embargo, el comportamiento heredado aún existe para los siguientes tipos de organizaciones:

Organizaciones con usuarios que tienen permiso para implementar aplicaciones de App Engine, pero no tienen permiso para actuar en nombre de la identidad de la cuenta de servicio predeterminada de App Engine.
Organizaciones con usuarios que tienen permiso para implementar entornos de Managed Airflow, pero no tienen permiso para actuar en nombre de cualquier cuenta de servicio.
Organizaciones con usuarios que tienen permiso para implementar recursos de Cloud Data Fusion, Dataflow o Managed Service para Apache Spark, pero que no tienen permiso para actuar en nombre de la cuenta de servicio predeterminada de Compute Engine.

Si tu organización aún se ve afectada por el comportamiento heredado, recibirás una comunicación que explica cómo inhabilitarla de forma manual. También puedes consultar las secciones que aparecen a continuación para obtener instrucciones detalladas.

Protege App Engine

A fin de inhabilitar de forma manual el comportamiento heredado de App Engine, asegúrate de que los usuarios tengan permiso para actuar en nombre de la cuenta de servicio de App Engine. Luego, habilita una restricción de política de la organización para aplicar de forma forzosa las verificaciones de permisos de las cuentas de servicio cuando se implementan aplicaciones que usan la identidad de la cuenta de servicio predeterminada de App Engine.

Opcional: Usa las recomendaciones de función para disminuir el alcance de forma segura de los permisos de la cuenta de servicio predeterminada de App Engine.

A la cuenta de servicio predeterminada de App Engine se le otorga la función de editor con mucho potencial de forma automática (roles/editor). Sin embargo, no recomendamos usar una función tan permisiva en la configuración de producción.

Nota: Para proteger aún más la organización, puedes inhabilitar la función automática de cuentas de servicio
Asegúrate de que todos los usuarios que implementan aplicaciones tengan la capacidad de actuar en nombre de la identidad de la cuenta de servicio predeterminada de App Engine.

Para proporcionar esta función, otorga a los usuarios una función que incluya el permiso iam.serviceAccounts.actAs, como la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puedes otorgar esta función en el proyecto o en la cuenta de servicio predeterminada de App Engine. Para obtener instrucciones, consulta Administra la identidad temporal como cuenta de servicio.

Nota: Si tienes una gran cantidad de proyectos, puedes usar el buscador de discrepancias de permisos a fin de encontrar a los usuarios que tienen permiso para implementar aplicaciones, pero no para actuar en nombre de la identidad de la cuenta de servicio predeterminada de App Engine.
Habilita la restricción de la política de la organización constraints/appengine.enforceServiceAccountActAsCheck para aplicar de forma forzosa las verificaciones de permisos de la cuenta de servicio cuando se implementan aplicaciones.

Nota: Esta restricción de política de la organización solo es visible en entornos que tienen el comportamiento heredado. Si no ves la restricción, significa que ya está aplicada en tu entorno.
Opcional: Usa el aplicador de políticas de la organización booleano para confirmar que se aplique la restricción de políticas de la organización en todos los proyectos.

Protege Managed Service para Apache Airflow

Para inhabilitar de forma manual el comportamiento heredado de Managed Airflow, asegúrate de que los usuarios tengan permiso para actuar en nombre de las cuentas de servicio que vinculan a entornos nuevos. Luego, habilita una restricción de política de la organización para aplicar de forma forzosa las verificaciones de permisos de las cuentas de servicio cuando adjuntas cuentas de servicio a los entornos.

Identifica todas las cuentas de servicio que están vinculadas a los entornos de Managed Airflow:
1. En la Google Cloud consola, ve a la página Composer environments.
  
  Ir a la página Composer environments
2. Haz clic en el nombre de un entorno.
3. En la pestaña Environment configuration, busca el campo Cuenta de servicio y registra el nombre de la cuenta de servicio.
4. Repite los pasos anteriores para todos los entornos de Managed Airflow en el proyecto.
Confirma que estas cuentas de servicio siguen el principio de privilegio mínimo:
- En la Google Cloud consola, ve a la página de IAM , busca las cuentas de servicio y revisa sus funciones.
  
  Ir a la página IAM
- Si es necesario, otorga una función menos permisiva a la cuenta de servicio. Puedes seleccionar un rol de la lista de roles predefinidos de IAM, usar un rol sugerido por una recomendación de rol o crear un rol personalizado.
Asegúrate de que todos los usuarios que implementan o administran entornos de Managed Airflow tengan la capacidad de suplantar a las cuentas de servicio que usan los entornos.

Para proporcionar esta función, otorga a los usuarios un rol que incluya el permiso iam.serviceAccounts.actAs, como el rol de usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puedes otorgar este rol en el proyecto o en una cuenta de servicio individual. Para obtener instrucciones, consulta Administra la identidad temporal como cuenta de servicio.

Nota: Si tienes una gran cantidad de proyectos, puedes usar el buscador de discrepancias de permisos a fin de encontrar a los usuarios que tienen permiso para implementar entornos de Managed Airflow pero no para actuar en nombre de la identidad de las cuentas de servicio.
Habilita la restricción de la política de la organización constraints/composer.enforceServiceAccountActAsCheck para aplicar de forma forzosa las verificaciones de permisos de la cuenta de servicio cuando se vinculan las cuentas de servicio a los entornos.

Nota: Esta restricción de política de la organización solo es visible en entornos que tienen el comportamiento heredado. Si no ves la restricción, significa que ya está aplicada en tu entorno.
Opcional: Usa el aplicador de políticas de la organización booleano para confirmar que se aplique la restricción de políticas de la organización en todos los proyectos.

Protege Managed Service para Apache Spark, Dataflow y Cloud Data Fusion

Para inhabilitar de forma manual el comportamiento heredado de Managed Service para Apache Spark, Dataflow y Cloud Data Fusion, asegúrate de que los usuarios tengan permiso para actuar en nombre de las cuentas de servicio que conectan a recursos nuevos. Luego, habilita las restricciones de las políticas de la organización para aplicar de forma forzosa las verificaciones de permisos de las cuentas de servicio cuando adjuntas cuentas de servicio a los recursos.

Sigue las instrucciones para el tipo de cuenta de servicio que deseas conectar a los recursos nuevos:

Si deseas dejar de conectar la cuenta de servicio predeterminada de Compute Engine a recursos nuevos, sigue estos pasos:

Nota: En Cloud Data Fusion, el uso de cuentas de servicio que no sean la cuenta de servicio predeterminada de Compute Engine solo está disponible para clientes de Cloud Data Fusion Enterprise. Para obtener más información, consulta Cuentas de servicio de Cloud Data Fusion.
1. Crea una cuenta de servicio nueva y otorga a la cuenta de servicio las funciones que necesita para ejecutar trabajos en el recurso. Asegúrate de seguir el principio de privilegio mínimo.
  
  A fin de saber qué funciones necesita una cuenta de servicio para ejecutar trabajos en los recursos de Managed Service para Apache Spark, Dataflow y Cloud Data Fusion, consulta los siguientes vínculos:
  - Requisitos de la cuenta de servicio de Managed Service para Apache Spark
  - Requisitos para las cuentas de servicio de Dataflow
  - Las cuentas de servicio de Cloud Data Fusion tienen los mismos requisitos que las cuentas de servicio de Managed Service para Apache Spark.
2. Permite que todos los usuarios que implementan estos recursos actúen en nombre de la cuenta de servicio nueva.
  
  Para proporcionar esta función, otorga a los usuarios una función que incluya el permiso iam.serviceAccounts.actAs, como la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puedes otorgar esta función en el proyecto o en la cuenta de servicio. Para obtener instrucciones, consulta Administra el robo de indentidad de cuentas de servicio.
3. Habilita las siguientes restricciones de política de la organización para aplicar las verificaciones de permiso de la cuenta de servicio cuando adjuntas cuentas de servicio a los recursos:
  - constraints/dataflow.enforceComputeDefaultServiceAccountCheck
  - constraints/dataproc.enforceComputeDefaultServiceAccountCheck
  Nota: La restricción de la política de la organización constraints/dataproc.enforceComputeDefaultServiceAccountCheck también aplica verificaciones de permisos para Cloud Data Fusion.
  
  Nota: Estas restricciones de las políticas de la organización solo se pueden ver en entornos que tienen el comportamiento heredado. Si no ves las restricciones, significa que ya se aplicaron en tu entorno.
4. Opcional: Usa el aplicador de políticas de la organización booleano para confirmar que las restricciones de las políticas de la organización se apliquen en todos los proyectos.
5. Cuando implementes recursos nuevos, usa la cuenta de servicio nueva en lugar de la cuenta de servicio predeterminada de Compute Engine.
Si deseas conectar la cuenta de servicio predeterminada de Compute Engine a recursos nuevos, sigue estos pasos:
1. Opcional: Usa las recomendaciones de roles para disminuir el alcance de forma segura de los permisos de la cuenta de servicio predeterminada de Compute Engine.
  
  A la cuenta de servicio predeterminada de Compute Engine se le otorga de forma automática la función de editor con mucho potencial (roles/editor). Sin embargo, no recomendamos usar una función tan permisiva en la configuración de producción.
  
  Nota: Para proteger aún más la organización, puedes inhabilitar la función automática de cuentas de servicio.
2. Asegúrate de que todos los usuarios que implementan estos recursos tengan la capacidad de actuar en nombre de la cuenta de servicio predeterminada de Compute Engine.
  
  Para proporcionar esta función, otorga a los usuarios una función que incluya el permiso iam.serviceAccounts.actAs, como la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puedes otorgar esta función en el proyecto o en la cuenta de servicio predeterminada de Compute Engine. Para obtener instrucciones, consulta Administra la identidad temporal como cuenta de servicio.
  
  Nota: Si tienes una gran cantidad de proyectos, puedes usar el buscador de discrepancias de permisos a fin de encontrar a los usuarios que tienen permiso para implementar recursos, pero no para actuar en nombre de la identidad de la cuenta de servicio predeterminada de Compute Engine.
3. Habilita las siguientes restricciones de política de la organización para aplicar las verificaciones de permiso de la cuenta de servicio cuando adjuntas cuentas de servicio a los recursos:
  - constraints/dataflow.enforceComputeDefaultServiceAccountCheck
  - constraints/dataproc.enforceComputeDefaultServiceAccountCheck
4. Opcional: Usa el aplicador de políticas de la organización booleano para confirmar que las restricciones de las políticas de la organización se apliquen en todos los proyectos.

Protege Dataform

Para inhabilitar de forma manual el comportamiento heredado de Dataform, asegúrate de que los usuarios tengan permiso para actuar en nombre de las cuentas de servicio que conectan a recursos de Dataform.

Verifica si hay problemas de permisos para evitar interrumpir tus flujos de trabajo. Para ello, consulta Cloud Logging para obtener entradas específicas de Dataform que indiquen que a una principal (usuario o cuenta de servicio) le falta el permiso iam.serviceAccounts.actAs requerido. Esto te permite identificar y resolver de forma proactiva cualquier discrepancia de acceso. Para obtener más información, consulta Verifica si hay problemas de permisos en Cloud Logging.
Para los usuarios o las cuentas de servicio que necesitan crear invocaciones de flujo de trabajo, otórgales el permiso para usar la identidad de la cuenta de servicio asociada con el repositorio de Dataform. Puedes proporcionar este permiso otorgando la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la cuenta de servicio específica. Para obtener más información, consulta Resuelve problemas de permisos.
Si usas una cuenta de servicio personalizada, otorga las siguientes funciones al agente de servicio predeterminado de Dataform en la cuenta de servicio personalizada:
- Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator): Es obligatorio para todas las operaciones del repositorio que usan una cuenta de servicio personalizada.
- Usuario de cuenta de servicio (roles/iam.serviceAccountUser): Solo es obligatorio si usas configuraciones de flujo de trabajo para programar o automatizar ejecuciones. Esta función permite que el agente de servicio predeterminado de Dataform ejecute tareas como la cuenta de servicio personalizada.
Audita periódicamente tus recursos de Dataform para garantizar el uso adecuado de la cuenta de servicio y las concesiones de permisos. Usa Cloud Asset Inventory para enumerar todos los recursos de los tipos dataform.Repository y dataform.WorkflowConfig y, luego, inspecciona el campo resource.data.serviceAccount para verificar qué cuenta de servicio se está usando. Si se usa una cuenta de servicio personalizada, verifica que el agente de servicio predeterminado de Dataform tenga las funciones de usuario de cuenta de servicio (roles/iam.serviceAccountUser) y creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en esa cuenta de servicio personalizada. Para obtener más información, consulta Audita las configuraciones de cuentas de servicio.