Las cuentas de servicio son identidades y recursos. Debido a que las cuentas de servicio son recursos que aceptan políticas de permisos, puedes permitir que otras principales accedan a las cuentas de servicio si les otorgas roles en una cuenta de servicio.
En esta página, se enumeran los roles que puedes otorgar a las principales para permitirles crear, administrar o actuar en nombre de cuentas de servicio. Administrar cuentas de servicio implica acciones como ver, actualizar, borrar, inhabilitar, habilitar y enumerar cuentas de servicio, además de administrar sus políticas de IAM. Actuar en nombre de una cuenta de servicio es cuando un usuario usa credenciales de corta duración para autenticarse como una cuenta de servicio. Por lo general, se usa para obtener acceso elevado de manera temporal. Para obtener más información sobre el robo de identidad de cuentas de servicio, consulta Robo de identidad de cuentas de servicio.
En esta página, también se describen los permisos que necesitas para trabajar con cuentas de servicio en ciertas situaciones comunes.
Roles de la cuenta de servicio
Puedes otorgar los siguientes roles a las principales para permitirles administrar o actuar en nombre de cuentas de servicio.
Para obtener información sobre cómo otorgar estos roles a un usuario, consulta lo siguiente:
- Para obtener información sobre cómo permitir que un usuario administre o actúe en nombre de una sola cuenta de servicio, consulta Administra el acceso a las cuentas de servicio.
- Para obtener información sobre cómo permitir que un usuario administre o actúe en nombre de todas las cuentas de servicio de tu proyecto, consulta Administra el acceso a los proyectos, las carpetas y las organizaciones.
Función de usuario de cuenta de servicio
El rol de usuario de cuenta de servicio (roles/iam.serviceAccountUser) incluye el permiso iam.serviceAccounts.actAs, que permite a las principales acceder de forma indirecta a todos los recursos que la cuenta de servicio puede realizar. Por ejemplo, si un miembro tiene el rol de usuario de cuenta de servicio en una cuenta de servicio y la cuenta de servicio tiene el rol de administrador de Cloud SQL (roles/cloudsql.admin) en el proyecto, el miembro puede actuar en nombre de una cuenta de servicio para crear una instancia de Cloud SQL.
Además, las principales con este rol pueden vincular una cuenta de servicio a un recurso.
Este rol no permite que las principales creen credenciales de corta duración para cuentas de servicio o usen la marca --impersonate-service-account en Google Cloud CLI Para completar estas tareas, también necesitas el rol de creador de tokens de cuentas de servicio.
Función de creador de tokens de cuenta de servicio
Esta función permite que las principales actúen en nombre de cuentas de servicio para hacer lo siguiente:
- Crear tokens de acceso de OAuth 2.0, que puedes usar para autenticar con las API de Google.
- Crea tokens de ID de OpenID Connect (OIDC)
- Firmar tokens web JSON (JWT) y BLOB binarios para que puedan usarse en la autenticación.
Consulta Crea credenciales para cuentas de servicio de corta duración si deseas obtener más detalles.
Los permisos de la función incluyen lo siguiente:
iam.serviceAccounts.getAccessToken: Te permite crear tokens de acceso de OAuth 2.0.iam.serviceAccounts.getOpenIdToken: Te permite crear tokens de ID de OpenID Connect (OIDC).iam.serviceAccounts.implicitDelegation: Permite que las cuentas de servicio obtengan tokens en una cadena de delegación.iam.serviceAccounts.signBlob: Te permite firmar BLOB binarios.iam.serviceAccounts.signJwt: Te permite firmar JWT.
Rol del usuario de Workload Identity
Este rol permite que los principales actúen en nombre de cuentas de servicio desde cargas de trabajo de GKE.
Los permisos de la función incluyen lo siguiente:
iam.serviceAccounts.getAccessToken: Te permite crear tokens de acceso de OAuth 2.0.iam.serviceAccounts.getOpenIdToken: Te permite crear tokens de ID de OpenID Connect (OIDC).
Permisos de cuentas de servicio para situaciones comunes
Las cuentas de servicio se pueden usar en muchas situaciones diferentes, y cada una de ellas requiere permisos específicos. En esta sección, se describen situaciones comunes y los permisos necesarios.
Conecta cuentas de servicio a recursos
Si deseas iniciar un trabajo de larga duración que se autentica como una cuenta de servicio, debes conectar una cuenta de servicio al recurso que ejecutará el trabajo.
Permisos:
- Permisos para crear el recurso
iam.serviceAccounts.actAs
Busca las funciones que incluyen estos permisos en la lista de funciones de los permisos.
Existen varios recursos diferentes de Google Cloud que pueden ejecutar trabajos de larga duración como cuentas de servicio. Algunos ejemplos de estos recursos incluyen los siguientes:
- VM de Compute Engine
- Aplicaciones de App Engine
- Cloud Functions
Cuando creas estos recursos, tienes la opción de conectar una cuenta de servicio. Esta cuenta de servicio actúa como la identidad del recurso.
A fin de crear un recurso y conectar una cuenta de servicio, necesitas permisos para crear ese recurso y actuar en nombre de la cuenta de servicio que conectarás al recurso. Cualquier función que incluya el permiso iam.serviceAccounts.actAs proporciona el permiso para actuar como la cuenta de servicio.
Después de crear el recurso y conectarle una cuenta de servicio, puedes iniciar un trabajo de larga duración en el recurso. El trabajo se ejecuta como la cuenta de servicio conectada al recurso y usa esa cuenta de servicio para autorizar solicitudes a las API de Google Cloud.
Para obtener más información sobre cómo conectar cuentas de servicio a recursos, consulta Conecta una cuenta de servicio a un recurso.
Actúa directamente como una cuenta de servicio
Permisos:
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
Funciones:
roles/iam.serviceAccountTokenCreator(Creador de tokens de cuenta de servicio)
Una vez que se le otorgan los permisos necesarios, un usuario (o servicio) puede actuar directamente como una cuenta de servicio (o confirmar la identidad de esta) en algunas situaciones comunes.
En primer lugar, el usuario puede obtener credenciales a corto plazo para la cuenta de servicio mediante el permiso iam.serviceAccounts.getAccessToken y a través de una llamada al método generateAccessToken(). Mediante el uso de credenciales a corto plazo, un usuario puede ejecutar comandos en Google Cloud y acceder a todos los recursos a los que tiene acceso la cuenta de servicio. Por ejemplo, este flujo permite que un usuario emplee la marca gcloud --impersonate-service-account para actuar como la cuenta de servicio sin que se requiera el uso de una clave de cuenta de servicio externa descargada.
En segundo lugar, el usuario puede obtener artefactos firmados por la clave privada administrada por Google de la cuenta de servicio mediante el permiso iam.serviceAccounts.signBlob y a través de una llamada a los métodos signBlob() o signJwt().
La clave privada administrada por Google siempre se mantiene guardada y nunca se expone directamente. signBlob() permite la firma de cargas útiles arbitrarias (como URLs firmadas por Cloud Storage), mientras que signJwt() solo permite firmar JWT con el formato correcto.
Por último, el usuario puede actuar como la cuenta de servicio (o confirmar la identidad de esta) sin tener que recuperar una credencial para la cuenta de servicio. Este es un caso práctico avanzado y solo se admite para el acceso programático mediante el método generateAccessToken(). En situaciones con al menos 3 cuentas de servicio, como A, B y C: la cuenta de servicio A puede obtener un token de acceso para la cuenta de servicio C si a la cuenta de servicio A se le otorga el permiso iam.serviceAccounts.implicitDelegation en B y B recibe el permiso iam.serviceAccounts.getAccessToken en C.
Genera tokens de ID de OpenID Connect (OIDC)
Permisos:
iam.serviceAccounts.getOpenIdToken
Funciones:
roles/iam.serviceAccountTokenCreator(Creador de tokens de cuenta de servicio)
Un usuario (o servicio) puede generar un token JWT compatible con OpenID Connect (OIDC) firmado por el proveedor de OIDC de Google (accounts.google.com) que represente la identidad de la cuenta de servicio que tiene el permiso iam.serviceAccounts.getOpenIdToken.
La mayoría de las API de Google no aceptan directamente estos tokens sin que tu organización implemente una federación de identidades adicional para otorgar acceso a Google. Existen algunas excepciones, por ejemplo, Identity-Aware Proxy, que permite el acceso basado en OIDC a aplicaciones ejecutadas por el usuario.
Genera claves privadas externas
Permisos:
iam.serviceAccountKeys.create
Funciones:
roles/editor(Editor)- Administrador de claves de cuentas de servicio (
roles/iam.serviceAccountKeyAdmin)
Un usuario o servicio puede generar material de la clave privada externa (RSA) que se puede usar para autenticarse directamente en Google como la cuenta de servicio. Este material de la clave se puede usar con bibliotecas de credenciales predeterminadas de la aplicación (ADC) o con el comando gcloud auth
activate-service-account. Cualquier persona que obtenga acceso al material de la clave tendrá acceso completo a todos los recursos a los que tenga acceso la cuenta de servicio. Este material de la clave privada debe tratarse con mucho cuidado y debe considerarse menos seguro cuanto más tiempo exista. Por lo tanto, rotar el material de la clave privada es fundamental para mantener una seguridad sólida.
Prácticas recomendadas para otorgar roles en cuentas de servicio
En los casos en los que una cuenta de servicio tiene permisos para realizar operaciones con muchos privilegios, ten cuidado cuando otorgues el rol de usuario de cuenta de servicio a un usuario en esa cuenta de servicio.
Las cuentas de servicio representan la seguridad a nivel de servicio. La seguridad del servicio se determina según las personas que tienen funciones de IAM que permiten administrar y usar las cuentas de servicio, y las personas que tienen claves de cuentas de servicio para esas cuentas de servicio. Las siguientes son recomendaciones para garantizar la seguridad:
- Usa la API de IAM para auditar las cuentas de servicio, las claves y las políticas en esas cuentas de servicio.
- Si tus cuentas de servicio no necesitan claves de cuenta de servicio, inhabilítalas o bórralas.
- Si los usuarios no necesitan permiso para administrar o usar cuentas de servicio, quítalos de la política de permisos aplicable.
- Asegúrate de que las cuentas de servicio tengan la menor cantidad de permisos posible. Usa las cuentas de servicio predeterminadas con precaución, ya que se les otorga de forma automática la función de editor (
roles/editor) en el proyecto.
Si deseas obtener más información sobre las prácticas recomendadas, consulta Prácticas recomendadas para trabajar con cuentas de servicio.
Pruébalo tú mismo
Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
Comenzar gratis