Las entidades pueden usar cuentas de servicio para autenticarse de varias formas. Cada tipo de autenticación requiere que la entidad tenga permisos de gestión de identidades y accesos (IAM) específicos en la cuenta de servicio.
En esta página se describen los roles que puedes asignar a las principales para que puedan suplantar cuentas de servicio o asociar cuentas de servicio a recursos. También se describen los permisos que necesitas en situaciones habituales.
Para obtener información sobre las diferentes formas de autenticarse con una cuenta de servicio, consulta los artículos Credenciales de cuenta de servicio y Suplantación de identidad de cuenta de servicio.
Roles de cuenta de servicio
En esta sección se describen los roles que permiten a las entidades autenticarse con cuentas de servicio. Para saber cómo conceder y revocar estos roles, consulta el artículo Gestionar el acceso a cuentas de servicio.
Rol Usuario de cuenta de servicio
El rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) permite que un principal asigne una cuenta de servicio a un recurso. Cuando el código que se ejecuta en ese recurso necesita autenticarse, puede obtener las credenciales de la cuenta de servicio adjunta.
Este rol no permite a las entidades de seguridad
crear credenciales de duración reducida para cuentas de servicio ni
usar la marca --impersonate-service-account en la
interfaz de línea de comandos de Google Cloud. Para completar estas tareas, necesitas el rol Creador de tokens de cuenta de servicio en la cuenta de servicio.
Rol Creador de tokens de cuenta de servicio
El rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) permite que las entidades principales creen credenciales de duración reducida para una cuenta de servicio.
El rol Creador de tokens de cuenta de servicio te permite crear los siguientes tipos de credenciales de corta duración:
- Tokens de acceso de OAuth 2.0, que puedes usar para autenticarte en las APIs de Google
- Tokens de ID de OpenID Connect (OIDC)
- JSON Web Tokens (JWTs) y blobs binarios firmados
El rol Creador de tokens de cuenta de servicio también permite que las entidades usen la marca --impersonate-service-account en la CLI de gcloud. Cuando usas esta marca, la CLI de gcloud crea automáticamente credenciales de corta duración para la cuenta de servicio.
Los permisos del rol 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 blobs binariosiam.serviceAccounts.signJwt: te permite firmar JWTs
Creador de tokens de identidad de OpenID Connect de cuenta de servicio
El rol Creador de tokens de identidad de OpenID Connect de cuenta de servicio (roles/iam.serviceAccountOpenIdTokenCreator) permite que las entidades principales creen tokens de ID de OIDC de corta duración. Si solo necesitas crear tokens de ID de OIDC, usa este rol. Si necesitas crear otros tipos de tokens, usa el rol Creador de tokens de cuenta de servicio.
El rol incluye el permiso iam.serviceAccounts.getOpenIdToken, que te permite crear un token de ID de OIDC.
Rol Usuario de Workload Identity
El rol Usuario de Workload Identity (roles/iam.workloadIdentityUser) permite que las entidades actúen como cuentas de servicio de cargas de trabajo de GKE.
Los permisos del rol incluyen lo siguiente:
iam.serviceAccounts.getAccessToken: te permite crear tokens de acceso de OAuth 2.0iam.serviceAccounts.getOpenIdToken: te permite crear tokens de ID de OpenID Connect (OIDC)
Permisos de cuenta de servicio para casos de uso habituales
Las cuentas de servicio se pueden usar en muchos casos prácticos diferentes, y cada uno de ellos requiere determinados permisos. En esta sección se describen situaciones habituales y los permisos necesarios.
Asociar cuentas de servicio a recursos
Si quieres iniciar un trabajo de larga duración que se autentique como una cuenta de servicio, debes asociar una cuenta de servicio al recurso que ejecutará el trabajo.
Permisos:
- Permisos para crear el recurso
iam.serviceAccounts.actAs
Para encontrar roles que incluyan estos permisos, busca los permisos en la lista de roles.
Hay varios Trusted Cloud recursos que pueden ejecutar trabajos de larga duración como cuentas de servicio. Estos son algunos ejemplos de estos recursos:
- Máquinas virtuales de Compute Engine
- Cloud Run Functions
Cuando creas estos recursos, tienes la opción de adjuntar una cuenta de servicio. Esta cuenta de servicio actúa como identidad del recurso.
Para crear un recurso y adjuntar una cuenta de servicio, debes tener permiso para crear ese recurso y permiso para adjuntar la cuenta de servicio a los recursos.
El permiso para asignar cuentas de servicio a recursos se proporciona mediante cualquier rol que incluya el permiso iam.serviceAccounts.actAs, como el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser).
Una vez que hayas creado el recurso y le hayas asociado una cuenta de servicio, podrás iniciar un trabajo de larga duración en el recurso. El trabajo se ejecuta como la cuenta de servicio que está asociada al recurso y usa esa cuenta para autorizar las solicitudes a lasTrusted Cloud APIs.
Para obtener más información sobre cómo asociar cuentas de servicio a recursos, consulta el artículo Asociar una cuenta de servicio a un recurso.
Suplantar la identidad de una cuenta de servicio
Permisos:
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
Roles:
roles/iam.serviceAccountTokenCreator(Creador de tokens de cuenta de servicio)
Una vez que se hayan concedido los permisos necesarios, un usuario (u otra cuenta de servicio) podrá suplantar la identidad de la cuenta de servicio en algunos casos habituales.
En primer lugar, el usuario puede autenticarse como la cuenta de servicio. Por ejemplo, pueden obtener credenciales de corta duración para la cuenta de servicio mediante el permiso iam.serviceAccounts.getAccessToken y llamando al método
generateAccessToken(). También pueden usar la
marca --impersonate-service-account de
la CLI de gcloud para suplantar la cuenta de servicio. Cuando un usuario se autentica como cuenta de servicio, puede enviar comandos aTrusted Cloud y acceder a todos los recursos a los que tenga acceso la cuenta de servicio.
En segundo lugar, el usuario puede obtener artefactos firmados por la clave privada gestionada por Google de la cuenta de servicio mediante el permiso iam.serviceAccounts.signBlob y llamando al método signBlob() o signJwt().
La clave privada gestionada por Google siempre se mantiene en depósito y nunca se expone directamente. signBlob() permite firmar cargas útiles arbitrarias (como URLs firmadas de Cloud Storage), mientras que signJwt() solo permite firmar JWTs bien formados.
Por último, el usuario puede suplantar la cuenta de servicio sin tener que obtener una credencial para la cuenta de servicio. Este es un caso práctico avanzado y solo se admite el acceso programático mediante el método generateAccessToken(). En situaciones en las que hay al menos 3 cuentas de servicio (A, B y C), la cuenta de servicio A puede obtener un token de acceso para la cuenta de servicio C si la cuenta de servicio A tiene el permiso iam.serviceAccounts.implicitDelegation en B y B tiene el permiso iam.serviceAccounts.getAccessToken en C.
Generar tokens de ID de OpenID Connect (OIDC)
Permisos:
iam.serviceAccounts.getOpenIdToken
Roles:
roles/iam.serviceAccountOpenIdTokenCreator(Creador de tokens de identidad de OpenID Connect de cuenta de servicio)
Un usuario (o un 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 mediante el permiso iam.serviceAccounts.getOpenIdToken.
La mayoría de las APIs de Google no aceptan estos tokens directamente a menos que tu organización implemente una federación de identidades adicional para conceder acceso a Google.
Generar claves privadas externas
Permisos:
iam.serviceAccountKeys.create
Roles:
roles/editor(editor)roles/iam.serviceAccountKeyAdmin(Administrador de claves de cuentas de servicio)
Un usuario o un servicio pueden generar material de clave privada externa (RSA) que se puede usar para autenticarse directamente en Google como cuenta de servicio. Este material de 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 clave privada debe tratarse con la máxima precaución y se considera menos seguro cuanto más tiempo se conserve. Por lo tanto, es fundamental rotar el material de la clave privada para mantener un nivel de seguridad alto.
Permisos de cuenta de servicio que habilitan otras funciones
Algunos permisos de las credenciales de la cuenta de servicio habilitan varias funciones.
Por ejemplo, iam.serviceAccounts.signBlob y iam.serviceAccounts.signJwt también permiten que los principales generen tokens de acceso y tokens de ID para una cuenta de servicio. Además, como iam.serviceAccounts.signBlob permite a las entidades firmar cualquier tipo de datos, también les permite firmar JWTs.
Antes de añadir cualquiera de estos permisos a roles personalizados, asegúrate de que entiendes qué acciones permite cada permiso.
En la siguiente tabla se muestran las operaciones que permiten estos permisos:
| Permiso | Operaciones habilitadas |
|---|---|
iam.serviceAccounts.getAccessToken |
Obtener un token de acceso para la cuenta de servicio |
iam.serviceAccounts.getOpenIdToken |
Obtener un token de ID de la cuenta de servicio |
iam.serviceAccounts.signJwt |
|
iam.serviceAccounts.signBlob |
|
Prácticas recomendadas para conceder roles en cuentas de servicio
En los casos en los que se hayan concedido permisos a una cuenta de servicio para realizar operaciones con privilegios elevados, ten cuidado al conceder el rol Usuario de cuenta de servicio o los permisos incluidos a un usuario de esa cuenta de servicio.
Las cuentas de servicio representan la seguridad a nivel de servicio. La seguridad del servicio depende de las personas que tengan roles de gestión de identidades y accesos para gestionar y usar las cuentas de servicio, así como de las personas que tengan claves de cuentas de servicio para esas cuentas. Estas son algunas de las prácticas recomendadas para garantizar la seguridad:
- Usa la API IAM para auditar las cuentas de servicio, las claves y las políticas de permiso de esas cuentas.
- Si tus cuentas de servicio no necesitan claves de cuenta de servicio, inhabilítalas o elimínalas.
- Si los usuarios no necesitan permiso para gestionar o usar cuentas de servicio, quítalos de la política de autorización correspondiente.
- Consulta cómo habilitar otras funciones concediendo determinados permisos a cuentas de servicio.
- Asegúrate de que las cuentas de servicio tengan los permisos mínimos posibles. Usa las cuentas de servicio predeterminadas con precaución, ya que se les asigna automáticamente el rol Editor (
roles/editor) en el proyecto.
Para obtener más información sobre las prácticas recomendadas, consulta el artículo Prácticas recomendadas para trabajar con cuentas de servicio.