Cuando creas ciertos recursos de Google Cloud, 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 API de Google Cloud.
En la mayoría de los servicios de Google Cloud, 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. |
Cloud Composer | Los usuarios podían conectar cualquier cuenta de servicio del proyecto a un entorno de Cloud Composer, incluso si no tenían permiso para actuar en nombre de cualquiera de las cuentas de servicio del proyecto. |
|
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. |
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 Cloud Composer, 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 Dataproc, 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.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 el robo de indentidad de cuentas de servicio.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.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 Cloud Composer
A fin de inhabilitar de forma manual el comportamiento heredado de Cloud Composer, 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 Cloud Composer:
En la consola de Google Cloud, ve a la página Entornos de Composer.
Haz clic en el nombre de un entorno.
En la pestaña Environment configuration, busca el campo Cuenta de servicio y registra el nombre de la cuenta de servicio.
Repite los pasos anteriores para todos los entornos de Cloud Composer en el proyecto.
Confirma que estas cuentas de servicio siguen el principio de privilegio mínimo:
En la consola de Google Cloud, ve a la página de IAM, busca las cuentas de servicio y revisa sus roles.
Si es necesario, otorga una función menos permisiva a la cuenta de servicio. Puedes seleccionar una función de la lista de Funciones predefinidas de IAM, usa una función sugerida por una recomendación de función o crea una función personalizada.
Asegúrate de que todos los usuarios que implementan o administran entornos de Cloud Composer tengan la capacidad de suplantar a las cuentas de servicio que usan los entornos.
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 una cuenta de servicio individual. Para obtener instrucciones, consulta Administra el robo de indentidad de 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.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 Dataproc, Dataflow y Cloud Data Fusion
A fin de inhabilitar de forma manual el comportamiento heredado de Dataproc, 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:
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 Dataproc, Dataflow y Cloud Data Fusion, consulta los siguientes vínculos:
- Requisitos para las cuentas de servicio de Dataproc
- 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 Dataproc.
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.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.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.
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:
Opcional: Usa las recomendaciones de roles 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 Compute 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.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 el robo de indentidad de cuentas de servicio.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
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.