Requerir permiso para asignar cuentas de servicio a recursos

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

En la mayoría de los Google Cloud servicios, los usuarios necesitan permiso para suplantar la identidad de una cuenta de servicio para poder asignar esa cuenta de servicio a un recurso. Esto significa que el usuario necesita el permiso iam.serviceAccounts.actAs en la cuenta de servicio.

Sin embargo, antes, algunos servicios permitían que los usuarios adjuntaran cuentas de servicio a recursos aunque no tuvieran permiso para suplantar la identidad de las cuentas de servicio. Es posible que esta configuración haya permitido que los usuarios de estos servicios obtuvieran permisos elevados no evidentes.

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

Servicio	Comportamiento antiguo
App Engine	Los usuarios podían desplegar aplicaciones de App Engine que usaran la identidad de la cuenta de servicio predeterminada de App Engine, aunque no tuvieran permiso para suplantar la identidad de dicha cuenta.
Cloud Composer	Los usuarios podían asociar cualquier cuenta de servicio del proyecto a un entorno de Cloud Composer, aunque no tuvieran permiso para suplantar la identidad de ninguna de las cuentas de servicio del proyecto.
Cloud Data Fusion Dataflow Dataproc	Los usuarios podían asociar la cuenta de servicio predeterminada de Compute Engine a los recursos, aunque no tuvieran permiso para suplantar la identidad de la cuenta de servicio predeterminada.

Ahora, estos servicios deben comprobar que los usuarios tengan permiso para suplantar cuentas de servicio al asignar las cuentas de servicio a los recursos. Sin embargo, el comportamiento antiguo sigue vigente para los siguientes tipos de organizaciones:

• Organizaciones con usuarios que tienen permiso para desplegar aplicaciones de App Engine, pero no para suplantar la cuenta de servicio predeterminada de App Engine.
• Organizaciones con usuarios que tienen permiso para desplegar entornos de Cloud Composer, pero no tienen permiso para suplantar la identidad de ninguna cuenta de servicio.
• Organizaciones con usuarios que tienen permiso para desplegar recursos de Cloud Data Fusion, Dataflow o Dataproc, pero no tienen permiso para suplantar la cuenta de servicio predeterminada de Compute Engine.

Si tu organización sigue afectada por el comportamiento antiguo, habrás recibido una comunicación en la que se explica cómo inhabilitarlo manualmente. También puede consultar las secciones siguientes para obtener instrucciones detalladas.

Proteger App Engine

Para inhabilitar manualmente el comportamiento antiguo de App Engine, asegúrate de que los usuarios tengan permiso para actuar en nombre de la cuenta de servicio de App Engine. A continuación, habilita una restricción de política de organización para aplicar comprobaciones de permisos de cuentas de servicio al implementar aplicaciones que usen la identidad de la cuenta de servicio predeterminada de App Engine.

1. Opcional: Usa las recomendaciones de roles para reducir de forma segura los permisos de la cuenta de servicio predeterminada de App Engine.

   A la cuenta de servicio predeterminada de App Engine se le concede automáticamente el rol Editor (roles/editor), que tiene muchos permisos. Sin embargo, no recomendamos usar un rol con tantos permisos en configuraciones de producción.

2. Asegúrate de que todos los usuarios que despliegan aplicaciones puedan suplantar la identidad de la cuenta de servicio predeterminada de App Engine.

   Para proporcionar esta función, asigna a los usuarios un rol que incluya el permiso iam.serviceAccounts.actAs, como el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puedes asignar este rol en el proyecto o en la cuenta de servicio predeterminada de App Engine. Para ver instrucciones al respecto, consulte el artículo sobre cómo gestionar la suplantación de identidad en cuentas de servicio.

3. Habilita la restricción de la política de organización constraints/appengine.enforceServiceAccountActAsCheck para aplicar las comprobaciones de permisos de la cuenta de servicio al implementar aplicaciones.

4. Opcional: Usa el enforcement de políticas de organización booleanas para confirmar que la restricción de la política de organización se aplica en todos tus proyectos.

Proteger Cloud Composer

Para inhabilitar manualmente el comportamiento antiguo de Cloud Composer, asegúrate de que los usuarios tengan permiso para suplantar las cuentas de servicio que adjunten a los nuevos entornos. A continuación, habilita una restricción de política de organización para aplicar comprobaciones de permisos de cuentas de servicio al asociar cuentas de servicio a entornos.

1. Identifica todas las cuentas de servicio vinculadas a entornos de Cloud Composer:

   1. En la Google Cloud consola, ve a la página Entornos de Composer.

      Ir a la página Entornos de Composer

   2. Haz clic en el nombre de un entorno.

   3. En la pestaña Configuración del entorno, busca el campo Cuenta de servicio y anota el nombre de la cuenta de servicio.

   4. Repita los pasos anteriores para todos los entornos de Cloud Composer de su proyecto.

2. Confirma que estas cuentas de servicio siguen el principio de mínimos accesos:

   • En la Google Cloud consola, ve a la página IAM, busca las cuentas de servicio y revisa sus roles.

     Ve a la página de gestión de identidades y accesos.

   • Si es necesario, concede un rol con menos permisos a la cuenta de servicio. Puedes seleccionar un rol de la lista de roles predefinidos de gestión de identidades y accesos, usar un rol sugerido por una recomendación de rol o crear un rol personalizado.

3. Asegúrate de que todos los usuarios que implementen o gestionen entornos de Cloud Composer puedan suplantar las cuentas de servicio que usen los entornos.

   Para ello, asigne a los usuarios un rol que incluya el permiso iam.serviceAccounts.actAs, como el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puede asignar este rol en el proyecto o en una cuenta de servicio concreta. Para ver instrucciones al respecto, consulte el artículo sobre cómo gestionar la suplantación de identidad en cuentas de servicio.

4. Habilita la restricción de la política de organización constraints/composer.enforceServiceAccountActAsCheck para aplicar comprobaciones de permisos de cuentas de servicio al adjuntar cuentas de servicio a entornos.

5. Opcional: Usa el enforcement de políticas de organización booleanas para confirmar que la restricción de la política de organización se aplica en todos tus proyectos.

Proteger Dataproc, Dataflow y Cloud Data Fusion

Para inhabilitar manualmente el comportamiento antiguo de Dataproc, Dataflow y Cloud Data Fusion, asegúrese de que los usuarios tengan permiso para suplantar las cuentas de servicio que adjunten a los recursos nuevos. A continuación, habilita las restricciones de la política de organización para aplicar comprobaciones de permisos de cuentas de servicio al asociar cuentas de servicio a recursos.

Sigue las instrucciones correspondientes al tipo de cuenta de servicio que quieras asociar a los recursos nuevos:

• Si quieres dejar de adjuntar la cuenta de servicio predeterminada de Compute Engine a los recursos nuevos, sigue estos pasos:

  1. Crea una cuenta de servicio y asigna a la cuenta de servicio los roles que necesita para ejecutar trabajos en el recurso. Asegúrate de seguir el principio de mínimos accesos.

     Para saber qué roles necesita una cuenta de servicio para ejecutar trabajos en recursos de Dataproc, Dataflow y Cloud Data Fusion, consulta lo siguiente:

     • Requisitos de la cuenta de servicio de Dataproc
     • Requisitos de la cuenta de servicio de Dataflow
     • Las cuentas de servicio de Cloud Data Fusion tienen los mismos requisitos que las cuentas de servicio de Dataproc.

  2. Permite que todos los usuarios que implementen estos recursos suplanten la identidad de la nueva cuenta de servicio.

     Para proporcionar esta función, asigne a los usuarios un rol que incluya el permiso iam.serviceAccounts.actAs, como el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puede asignar este rol en el proyecto o en la cuenta de servicio. Para ver instrucciones al respecto, consulte el artículo sobre cómo gestionar la suplantación de identidad en cuentas de servicio.

  3. Habilita las siguientes restricciones de la política de organización para aplicar comprobaciones de permisos de cuentas de servicio al asociar cuentas de servicio a recursos:

     • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
     • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

     La restricción de la política de la organización constraints/dataproc.enforceComputeDefaultServiceAccountCheck también aplica comprobaciones de permisos para Cloud Data Fusion.

  4. Opcional: Usa el enforcement de políticas de organización booleanas para confirmar que las restricciones de las políticas de organización se aplican en todos tus proyectos.

  5. Cuando implementes recursos nuevos, usa la nueva cuenta de servicio en lugar de la cuenta de servicio predeterminada de Compute Engine.

• Si quieres seguir asociando la cuenta de servicio predeterminada de Compute Engine a los nuevos recursos, sigue estos pasos:

  1. Opcional: Usa las recomendaciones de roles para reducir de forma segura los permisos de la cuenta de servicio predeterminada de Compute Engine.

     La cuenta de servicio predeterminada de Compute Engine recibe automáticamente el rol Editor, que tiene muchos permisos (roles/editor). Sin embargo, no recomendamos usar un rol con tantos permisos en configuraciones de producción.

  2. Asegúrate de que todos los usuarios que implementen estos recursos puedan suplantar la cuenta de servicio predeterminada de Compute Engine.

     Para proporcionar esta función, asigne a los usuarios un rol que incluya el permiso iam.serviceAccounts.actAs, como el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser). Puede asignar este rol en el proyecto o en la cuenta de servicio predeterminada de Compute Engine. Para ver instrucciones al respecto, consulte el artículo sobre cómo gestionar la suplantación de identidad en cuentas de servicio.

  3. Habilita las siguientes restricciones de la política de organización para aplicar las comprobaciones de permisos de las cuentas de servicio al asociar cuentas de servicio a recursos:

     • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
     • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

  4. Opcional: Usa el enforcement de políticas de organización booleanas para confirmar que las restricciones de las políticas de organización se aplican en todos tus proyectos.