En esta página se explica qué son las cuentas de servicio y se describen consideraciones importantes para gestionar las cuentas de servicio en cada fase de su ciclo de vida.
¿Qué son las cuentas de servicio?
Una cuenta de servicio es un tipo especial de cuenta que suelen usar las aplicaciones o las cargas de trabajo de computación, como las instancias de Compute Engine, en lugar de las personas. Las cuentas de servicio se identifican por su dirección de correo, que es única para cada cuenta.
Las aplicaciones usan cuentas de servicio para hacer llamadas a la API autorizadas autenticándose como la propia cuenta de servicio. Cuando una aplicación se autentica como una cuenta de servicio, tiene acceso a todos los recursos a los que la cuenta de servicio tiene permiso para acceder.
La forma más habitual de permitir que una aplicación se autentique como cuenta de servicio es asignar una cuenta de servicio al recurso que ejecuta la aplicación. Por ejemplo, puedes asociar una cuenta de servicio a una instancia de Compute Engine para que las aplicaciones que se ejecuten en esa instancia puedan autenticarse como la cuenta de servicio. Después, puedes conceder roles de gestión de identidades y accesos a la cuenta de servicio para que esta (y, por extensión, las aplicaciones de la instancia) pueda acceder a los Trusted Cloud recursos.
Hay otras formas de permitir que las aplicaciones se autentiquen como cuentas de servicio además de adjuntar una cuenta de servicio. Por ejemplo, puedes configurar Federación de identidades de cargas de trabajo para permitir que las cargas de trabajo externas se autentiquen como cuentas de servicio o crear una clave de cuenta de servicio y usarla en cualquier entorno para obtener tokens de acceso de OAuth 2.0.
Para obtener más información sobre la autenticación de cuentas de servicio para aplicaciones, consulta el artículo Descripción general de las identidades de las cargas de trabajo.
Las entidades, como los usuarios y otras cuentas de servicio, también pueden autenticarse como cuentas de servicio. Para obtener más información, consulta la sección Suplantación de identidad de cuentas de servicio de esta página.
Tipos de cuentas de servicio
En Trusted Cloud, hay varios tipos de cuentas de servicio:
Cuentas de servicio gestionadas por el usuario: cuentas de servicio que creas y gestionas. Estas cuentas de servicio se suelen usar como identidades de cargas de trabajo.
Cuentas de servicio predeterminadas: cuentas de servicio gestionadas por el usuario que se crean automáticamente cuando habilitas determinados Trusted Cloud servicios. Eres responsable de gestionar estas cuentas de servicio.
Agentes de servicio: cuentas de servicio creadas y gestionadas porTrusted Cloudque permiten a los servicios acceder a recursos en tu nombre.
Para obtener más información sobre los distintos tipos de cuentas de servicio, consulta el artículo Tipos de cuentas de servicio.
Credenciales de cuenta de servicio
Las aplicaciones y las entidades se autentican como cuentas de servicio de una de las siguientes formas:
- Obtener credenciales de duración reducida. En muchos casos, como las cuentas de servicio asociadas y los comandos que usan la marca
--impersonate-service-accountde la CLI de gcloud, estas credenciales se obtienen automáticamente, por lo que no tienes que crearlas ni gestionarlas tú. - Usar una clave de cuenta de servicio para firmar un JSON Web Token (JWT) e intercambiarlo por un token de acceso. Las claves de cuentas de servicio suponen un riesgo para la seguridad si no se gestionan correctamente, por lo que deberías elegir una alternativa más segura a las claves de cuentas de servicio siempre que sea posible.
Para obtener más información sobre la autenticación con cuentas de servicio, consulta Credenciales de cuentas de servicio.
Suplantación de identidad de cuentas de servicio
Cuando un principal autenticado, como un usuario u otra cuenta de servicio, se autentica como una cuenta de servicio para obtener sus permisos, se denomina suplantación de identidad de la cuenta de servicio. Al usar la identidad de una cuenta de servicio, un principal autenticado puede acceder a todo lo que pueda acceder la cuenta de servicio. Solo las entidades autenticadas con los permisos adecuados pueden suplantar cuentas de servicio.
La suplantación de identidad es útil cuando quieres cambiar los permisos de un usuario sin modificar tus políticas de gestión de identidades y accesos (IAM). Por ejemplo, puedes usar la suplantación de identidad para conceder temporalmente a un usuario acceso elevado o para comprobar si un conjunto específico de permisos es suficiente para una tarea. También puedes usar la suplantación para desarrollar aplicaciones de forma local que solo se puedan ejecutar como una cuenta de servicio o para autenticar aplicaciones que se ejecuten fuera de Trusted Cloud.
Para obtener más información sobre la suplantación de identidad de cuentas de servicio, consulta el artículo Suplantación de identidad de cuentas de servicio.
Permisos de cuenta de servicio
Las cuentas de servicio son principales. Esto significa que puedes conceder acceso a los recursos a las cuentas de servicio. Trusted Cloud Por ejemplo, puedes conceder a una cuenta de servicio el rol Administrador de Compute (roles/compute.admin) en un proyecto. De esta forma, la cuenta de servicio podría gestionar los recursos de Compute Engine de ese proyecto.
Sin embargo, las cuentas de servicio también son recursos. Esto significa que puedes dar permiso a otras cuentas principales para que accedan a la cuenta de servicio. Por ejemplo, puedes asignar a un usuario el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) en una cuenta de servicio para que pueda asociar esa cuenta de servicio a recursos. También puedes asignar a un usuario el rol Administrador de cuenta de servicio (roles/iam.serviceAccountAdmin) para que pueda ver, editar, inhabilitar y eliminar la cuenta de servicio.
En las siguientes secciones se explica cómo gestionar las cuentas de servicio como principales y como recursos.
Cuentas de servicio como principales
Como las cuentas de servicio son principales, puedes gestionar el acceso a ellas igual que lo harías con cualquier otro principal. Por ejemplo, si quieres que la cuenta de servicio de tu aplicación acceda a los objetos de un segmento de Cloud Storage, puedes concederle el rol de lector de objetos de almacenamiento (roles/storage.objectViewer) en el segmento. O bien, si quieres asegurarte de que la cuenta de servicio de una aplicación no pueda cambiar las políticas de gestión de identidades y accesos de un proyecto, puedes usar una política de denegación para impedir que la cuenta de servicio use el permiso resourcemanager.projects.setIamPolicy en ese proyecto. Para obtener más información sobre cómo gestionar el acceso de las entidades, consulta Acceso enTrusted Cloud.
Puedes gestionar el acceso de cuentas de servicio concretas o de todas las cuentas de servicio de un proyecto, una carpeta o una organización específicos. Cuando gestiones el acceso a las cuentas de servicio, usa los siguientes identificadores principales para hacer referencia a las cuentas de servicio:
| Tipo de principal | Identificador principal |
|---|---|
| Una cuenta de servicio individual |
Ejemplo: |
| Todas las cuentas de servicio de un proyecto |
Ejemplo: |
| Todas las cuentas de servicio de todos los proyectos de una carpeta |
Ejemplo: |
| Todas las cuentas de servicio de todos los proyectos de una organización |
Ejemplo: |
Al igual que con todos los tipos de principales, solo debes dar a la cuenta de servicio el conjunto mínimo de permisos necesarios para lograr su objetivo.
Si las cuentas de servicio de un proyecto, una carpeta o una organización específicos comparten requisitos, utiliza conjuntos de principales de cuentas de servicio para asignarles roles en lugar de usar grupos personalizados.
Para saber cómo asignar roles a principales, incluidas las cuentas de servicio, consulta el artículo Administra el acceso a proyectos, carpetas y organizaciones.
Cuentas de servicio como recursos
Las cuentas de servicio también son recursos que pueden tener sus propias políticas de permiso. Por lo tanto, puedes permitir que otros principales accedan a una cuenta de servicio concediéndoles un rol en la cuenta de servicio o en uno de los recursos principales de la cuenta de servicio. Por ejemplo, para permitir que un usuario suplante la identidad de una cuenta de servicio, puedes asignarle el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en la cuenta de servicio.
Cuando asignes un rol que permita a un usuario suplantar la identidad de una cuenta de servicio, ten en cuenta que el usuario podrá acceder a todos los recursos a los que pueda acceder la cuenta de servicio. Ten cuidado al permitir que los usuarios suplanten la identidad de cuentas de servicio con muchos privilegios, como la cuenta de servicio predeterminada de Compute Engine.
Para obtener más información sobre los roles que puedes conceder a las cuentas principales en cuentas de servicio, consulta Permisos de cuenta de servicio.
Para saber cómo conceder un rol a un principal en una cuenta de servicio, consulta Gestionar el acceso a cuentas de servicio.
Ciclo de vida de las cuentas de servicio
A medida que gestiones tus proyectos, es probable que crees, gestiones y elimines muchas cuentas de servicio diferentes. En esta sección se describen las consideraciones clave para gestionar tus cuentas de servicio en las distintas fases de su ciclo de vida.
Dónde crear cuentas de servicio
Cada cuenta de servicio se encuentra en un proyecto. Una vez que hayas creado una cuenta de servicio, no podrás moverla a otro proyecto.
Hay varias formas de organizar tus cuentas de servicio en proyectos:
Crea cuentas de servicio y recursos en el mismo proyecto.
Con este método, es más fácil empezar a usar las cuentas de servicio. Sin embargo, puede ser difícil hacer un seguimiento de tus cuentas de servicio cuando están repartidas en muchos proyectos.
Centraliza las cuentas de servicio en proyectos independientes.
De esta forma, todas las cuentas de servicio de tu organización se agrupan en un número reducido de proyectos, lo que facilita su gestión. Sin embargo, requiere una configuración adicional si vinculas cuentas de servicio a recursos de otros proyectos, lo que permite que esos recursos usen la cuenta de servicio como identidad.
Cuando una cuenta de servicio está en un proyecto y accede a un recurso de otro proyecto, normalmente debes habilitar la API de ese recurso en ambos proyectos. Por ejemplo, si tienes una cuenta de servicio en el proyecto
my-service-accountsy una instancia de Cloud SQL en el proyectomy-application, debes habilitar la API Cloud SQL enmy-service-accountsymy-application.De forma predeterminada, puedes crear hasta 100 cuentas de servicio en un proyecto. Si necesitas crear más cuentas de servicio, solicita un ajuste de cuota.
Para saber cómo crear una cuenta de servicio, consulta el artículo Crear cuentas de servicio.
Impedir la creación de cuentas de servicio
Para controlar mejor dónde se crean las cuentas de servicio, puedes impedir que se creen en algunos proyectos de tu organización.
Puedes impedir la creación de cuentas de servicio aplicando la constraints/iam.disableServiceAccountCreation
restricción de política de organización en una organización, un proyecto o una carpeta.
Antes de aplicar esta restricción, ten en cuenta las siguientes limitaciones:
Si aplicas esta restricción en un proyecto o en todos los proyectos de una organización, algunos servicios no podrán crear cuentas de servicio predeterminadas. Trusted Cloud Por lo tanto, si el proyecto ejecuta cargas de trabajo que necesitan autenticarse como una cuenta de servicio, es posible que el proyecto no contenga una cuenta de servicio que la carga de trabajo pueda usar.
Para solucionar este problema, puedes habilitar la suplantación de identidad de cuentas de servicio en varios proyectos. Cuando habilitas esta función, puedes crear cuentas de servicio en un proyecto centralizado y, a continuación, vincularlas a recursos de otros proyectos. Las cargas de trabajo que se ejecutan en esos recursos pueden usar las cuentas de servicio asociadas para autenticarse, por lo que las cuentas de servicio predeterminadas no son necesarias.
Para usar algunas funciones, como Federación de Identidades de Cargas de Trabajo, debes crear cuentas de servicio.
Si no usas la federación de identidades de cargas de trabajo, considera la posibilidad de usar restricciones de políticas de la organización para bloquear la federación de todos los proveedores de identidades.
Hacer un seguimiento de las cuentas de servicio
Con el tiempo, a medida que crees más cuentas de servicio, es posible que pierdas la pista de para qué se usa cada una.
El nombre visible de una cuenta de servicio es una buena forma de incluir información adicional sobre la cuenta, como su finalidad o la persona de contacto. En el caso de las cuentas de servicio nuevas, puedes
rellenar el nombre visible al crear la cuenta de servicio. En el caso de las cuentas de servicio, utiliza el método serviceAccounts.update() para modificar el nombre visible.
Usar cuentas de servicio con Compute Engine
Las instancias de Compute Engine deben ejecutarse como cuentas de servicio para tener acceso a otros recursos Trusted Cloud . Para proteger tus instancias de Compute Engine, ten en cuenta lo siguiente:
Puedes crear instancias en el mismo proyecto con diferentes cuentas de servicio. Para cambiar la cuenta de servicio de una instancia después de crearla, usa el método
instances.setServiceAccount.Para configurar la autorización de las cuentas de servicio asociadas, debes configurar los permisos de acceso, además de los roles de gestión de identidades y accesos.
Como las instancias dependen de sus cuentas de servicio para acceder a los recursos deTrusted Cloud , no elimines las cuentas de servicio cuando las instancias en ejecución aún las utilicen.
Para obtener más información sobre el uso de cuentas de servicio con Compute Engine, consulta el artículo Cuentas de servicio de la documentación de Compute Engine.
Identificar cuentas de servicio no utilizadas
Después de un tiempo, es posible que tengas cuentas de servicio en tus proyectos que ya no utilices.
Las cuentas de servicio que no se utilizan suponen un riesgo de seguridad innecesario, por lo que te recomendamos que inhabilites las cuentas de servicio que no se utilicen y, a continuación, elimines las cuentas de servicio cuando tengas la certeza de que ya no las necesitas. Puedes usar las métricas de uso de cuentas de servicio para monitorizar el uso de cuentas de servicio y claves.
Eliminar cuentas de servicio
Antes de eliminar una cuenta de servicio, inhabilítala para asegurarte de que no es necesaria. Las cuentas de servicio inhabilitadas se pueden volver a habilitar si siguen en uso.
Una vez que hayas confirmado que no necesitas una cuenta de servicio, puedes eliminarla.
Volver a crear cuentas de servicio eliminadas
Es posible eliminar una cuenta de servicio y, a continuación, crear otra con el mismo nombre.
Cuando eliminas una cuenta de servicio, sus enlaces de rol no se eliminan inmediatamente. En su lugar, la lista de enlaces de roles muestra la cuenta de servicio con el prefijo deleted:. Para ver un ejemplo, consulta Políticas con principales eliminados.
Si creas una cuenta de servicio con el mismo nombre que una cuenta de servicio eliminada recientemente, es posible que las vinculaciones antiguas sigan existiendo. Sin embargo, no se aplicarán a la nueva cuenta de servicio, aunque ambas cuentas tengan la misma dirección de correo. Este comportamiento se produce porque las cuentas de servicio tienen un ID único en Gestión de Identidades y Accesos (IAM) desde el momento en el que se crean. Internamente, todas las vinculaciones de roles se conceden con estos IDs, no con la dirección de correo de la cuenta de servicio. Por lo tanto, las vinculaciones de roles de una cuenta de servicio eliminada no se aplicarán a una nueva cuenta de servicio que tenga la misma dirección de correo.
Del mismo modo, si vinculas una cuenta de servicio a un recurso, eliminas la cuenta de servicio y creas una nueva con el mismo nombre, la nueva cuenta de servicio no se vinculará al recurso.
Para evitar este comportamiento inesperado, te recomendamos que uses un nombre nuevo y único para cada cuenta de servicio. Además, si eliminas una cuenta de servicio por error, puedes intentar restaurarla en lugar de crear una nueva.
Si no puedes restaurar la cuenta de servicio original y necesitas crear una cuenta de servicio con el mismo nombre y los mismos roles, debes conceder los roles a la nueva cuenta de servicio. Para obtener más información, consulta Políticas con principales eliminados.
Si también necesitas que la nueva cuenta de servicio se asigne a los mismos recursos que la cuenta de servicio original, haz una de las siguientes acciones:
- En el caso de las instancias de Compute Engine, puedes cambiar la cuenta de servicio asociada a la instancia para sustituir la cuenta de servicio original por la nueva.
- En el caso de los demás recursos, debes eliminar el recurso, crear otro del mismo tipo y adjuntar la nueva cuenta de servicio.
Siguientes pasos
- Consulta cómo crear cuentas de servicio.
- Consulta las prácticas recomendadas para trabajar con cuentas de servicio.
- Consulta las prácticas recomendadas para gestionar las claves de cuentas de servicio.