En esta página, se explica qué son las cuentas de servicio y se describen las consideraciones importantes para administrar las cuentas de servicio en cada etapa de su ciclo de vida.
¿Qué son las cuentas de servicio?
Una cuenta de servicio es un tipo especial de cuenta que, por lo general, es usada por una carga de trabajo de aplicación o procesamiento, como una instancia de Compute Engine, en lugar de una persona. Una cuenta de servicio se identifica por su dirección de correo electrónico, que es única a la cuenta.
Las aplicaciones usan cuentas de servicio para hacer llamadas a la API autorizadas, autorizadas como la cuenta de servicio en sí o como usuarios de Google Workspace o Cloud Identity a través de delegación de todo el dominio. Cuando una aplicación se autentica como una cuenta de servicio, tiene acceso a todos los recursos a los que tiene acceso la cuenta de servicio.
La forma más común de permitir que una aplicación se autentique como una cuenta de servicio es conectar una cuenta de servicio al recurso que ejecuta la aplicación. Por ejemplo, puedes conectar una cuenta de servicio a una instancia de Compute Engine para que las aplicaciones que se ejecutan en esa instancia puedan autenticarse como la cuenta de servicio. Luego, puedes otorgar los roles de IAM de la cuenta de servicio para permitir que la cuenta de servicio (y, por extensión, las aplicaciones de la instancia) accedan a los recursos de Google Cloud.
Hay otras formas de permitir que las aplicaciones se autentiquen como cuentas de servicio, además de conectar una cuenta de servicio. Por ejemplo, puedes configurar la federación de identidades para 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.
Si quieres obtener más información sobre la autenticación de la cuenta de servicio para las aplicaciones, consulta Descripción general de las identidades para las cargas de trabajo.
Las principales, 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 cuentas de servicio en esta página.
Tipos de cuentas de servicio
En Google Cloud, existen varios tipos diferentes de cuentas de servicio:
Cuentas de servicio administradas por el usuario: Son las cuentas de servicio que creas y administras. Estas cuentas de servicio se suelen usar como identidades para cargas de trabajo.
Cuentas de servicio predeterminadas: Son cuentas de servicio administradas por el usuario que se crean de forma automática cuando habilitas ciertos servicios de Google Cloud. Eres responsable de administrar estas cuentas de servicio.
Agentes de servicio: Son cuentas de servicio que crea y administra Google Cloud, y que permiten que los servicios accedan a los recursos en tu nombre.
Para obtener más información sobre los diferentes tipos de cuentas de servicio, consulta Tipos de cuentas de servicio.
Credenciales de cuenta de servicio
Las aplicaciones y las principales se autentican como una cuenta de servicio mediante una de las siguientes acciones:
- Obtener credenciales de corta duración. En muchos casos, como las cuentas de servicio conectadas y los comandos que usan la marca
--impersonate-service-accountde gcloud CLI, estas credenciales se obtienen de forma automática, no es necesario que las crees o las administres. - Usa una clave de cuenta de servicio para firmar un token web JSON (JWT) y, luego, intercambiarlo por un token de acceso. Debido a que las claves de las cuentas de servicio son un riesgo para la seguridad si no se administran de forma correcta, debes elegir una alternativa más segura que las claves de cuentas de servicio siempre que sea posible.
Para obtener más información sobre la autenticación de cuentas de servicio, consulta Credenciales de la cuenta de servicio.
Identidad temporal como cuenta de servicio
Cuando un principal autenticado, como un usuario o cualquier otra cuenta de servicio, se autentica como una cuenta de servicio para obtener los permisos de la cuenta de servicio, se llama actuar en nombre de la cuenta de servicio. Actuar en nombre de una cuenta de servicio permite que una principal autenticada acceda a lo que puede acceder la cuenta de servicio. Solo las principales autenticadas con los permisos adecuados pueden imitar cuentas de servicio.
Actuar en nombre de una cuenta es útil cuando deseas cambiar los permisos de un usuario sin cambiar las políticas de Identity and Access Management (IAM). Por ejemplo, puedes usar la identidad temporal para otorgar de forma temporal a un usuario acceso elevado o para probar si un conjunto específico de permisos es suficiente para una tarea. También puedes usar la identidad temporal para desarrollar aplicaciones que se ejecuten solo como una cuenta de servicio o para autenticar aplicaciones que se ejecutan fuera de Google Cloud.
Para obtener más información sobre la identidad temporal como cuenta de servicio, consulta Identidad temporal como cuenta de servicio.
Cuentas de servicio y dominios de Google Workspace
A diferencia de las cuentas de usuario, las cuentas de servicio no pertenecen a tu dominio de Google Workspace. Si compartes elementos de Google Workspace, como documentos o eventos, con todo tu dominio de Google Workspace, no se compartirán con las cuentas de servicio. Del mismo modo, los elementos de Google Workspace que crea una cuenta de servicio no se crean en el dominio de Google Workspace. Como resultado, los administradores de Google Workspace y Cloud Identity no pueden ser propietarios ni administrar estos elementos.
Permisos de las cuentas de servicio
Las cuentas de servicio son principales. Esto significa que puedes otorgarles a las cuentas de servicio acceso a los recursos de Google Cloud. Por ejemplo, puedes otorgar el rol de administrador de Compute (roles/compute.admin) a una cuenta de servicio en un proyecto. Luego, la cuenta de servicio podría administrar los recursos de Compute Engine en ese proyecto.
Sin embargo, las cuentas de servicio también son recursos. Esto significa que puedes otorgar permiso a otras principales para acceder a la cuenta de servicio. Por ejemplo, puedes otorgar a un usuario el rol de usuario de cuenta de servicio (roles/iam.serviceAccountUser) en una cuenta de servicio para permitir que conecte esa cuenta a los recursos. O bien, puedes otorgar el rol de administrador de cuentas de servicio (roles/iam.serviceAccountAdmin) a un usuario para permitirle hacer acciones como ver, cambiar, inhabilitar y borrar la cuenta de servicio.
En las siguientes secciones, se analiza cómo administrar cuentas de servicio como principales y como recursos.
Cuentas de servicio como principales
Debido a que las cuentas de servicio son principales, puedes permitir que una cuenta de servicio acceda a los recursos de tu proyecto si le otorgas un rol, al igual que lo harías con cualquier otra principal. Por ejemplo, si deseas permitir que la cuenta de servicio de tu aplicación acceda a los objetos en un bucket de Cloud Storage, puedes otorgar a la cuenta de servicio el rol de visualizador de objetos de almacenamiento (roles/storage.objectViewer) en el bucket.
Al igual que con todos los tipos de principales, solo debes otorgar a la cuenta de servicio el conjunto de permisos mínimos necesarios para que logre su objetivo.
Al igual que con otros principales, puedes agregar cuentas de servicio a un grupo y, luego, otorgar roles al grupo. Sin embargo, no se recomienda agregar cuentas de servicio a los grupos. Las aplicaciones usan cuentas de servicio, y es probable que cada una tenga sus propios requisitos de acceso.
Para obtener información sobre cómo otorgar roles a las principales, incluidas las cuentas de servicio, consulta Administra el acceso a los proyectos, las carpetas y las organizaciones.
Cuentas de servicio como recursos
Las cuentas de servicio también son recursos que pueden tener sus propias políticas de permisos. Como resultado, puedes permitir que otras principales accedan a una cuenta de servicio si les otorgas un rol en la cuenta de servicio o en uno de los recursos superiores de la cuenta de servicio. Por ejemplo, para permitir que un usuario actúe en nombre de una cuenta de servicio, puedes otorgarle al usuario el rol Service Account User (roles/iam.serviceAccountTokenCreator) en cuenta de servicio.
Cuando se otorga un rol que permite que un usuario actúe en nombre de una cuenta de servicio, ten en cuenta que puede acceder a todos los recursos a los que puede acceder la cuenta de servicio. Ten cuidado cuando permitas que los usuarios actúen en nombre de cuentas de servicio con muchos privilegios, como las cuentas de servicio predeterminadas de Compute Engine y App Engine.
Para obtener más información sobre los roles que puedes otorgar a las principales en las cuentas de servicio, consulta Permisos de las cuentas de servicio.
Para obtener información sobre cómo otorgar a una principal un rol en una cuenta de servicio, consulta Administra el acceso a las cuentas de servicio.
Ciclo de vida de la cuenta de servicio
Cuando administras tus proyectos, es probable que crees, administres y borres muchas cuentas de servicio diferentes. En esta sección, se describen las consideraciones clave para administrar las cuentas de servicio en las distintas etapas de su ciclo de vida.
Dónde crear cuentas de servicio
Cada cuenta de servicio está ubicada en un proyecto. Después de crear una cuenta de servicio, no puedes moverla a un proyecto diferente.
Hay algunas formas de organizar tus cuentas de servicio en proyectos:
Crea cuentas de servicio y recursos en el mismo proyecto.
Con este enfoque, es fácil empezar a usar las cuentas de servicio. Sin embargo, puede ser difícil hacer un seguimiento de tus cuentas de servicio cuando se distribuyen en muchos proyectos.
Centraliza las cuentas de servicio en proyectos diferentes.
Este enfoque coloca todas las cuentas de servicio de tu organización en una pequeña cantidad de proyectos, lo que puede facilitar la administración de las cuentas de servicio. Sin embargo, requiere una configuración adicional si conectas cuentas de servicio a recursos en otros proyectos, lo que permite que esos recursos usen la cuenta de servicio como su identidad.
Cuando una cuenta de servicio está en un proyecto y accede a un recurso en otro proyecto, por lo general, debes habilitar la API para 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 de Cloud SQL en ambosmy-service-accountsymy-application.Según la configuración predeterminada, puedes crear hasta 100 cuentas de servicio en un proyecto. Si necesitas crear cuentas de servicio adicionales, solicita un aumento de la cuota.
Para obtener información sobre cómo crear una cuenta de servicio, consulta Crea cuentas de servicio.
Impide la creación de cuentas de servicio
Para controlar mejor dónde se crean las cuentas de servicio, es posible que desees evitar la creación de cuentas de servicio en algunos proyectos de tu organización.
Puedes evitar la creación de cuentas de servicio si aplicas la restricción de la política de la organización constraints/iam.disableServiceAccountCreation 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 de Google Cloud no podrán crear cuentas de servicio predeterminadas. Como resultado, 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 identidad temporal como cuenta de servicio en todos los proyectos. Cuando habilitas esta función, puedes crear cuentas de servicio en un proyecto centralizado y, luego, conectar las cuentas de servicio a los recursos en otros proyectos. Las cargas de trabajo que se ejecutan en esos recursos pueden usar las cuentas de servicio conectadas para autenticarse, lo que hace que las cuentas de servicio predeterminadas sean innecesarias.
Algunas funciones, como la federación de identidades para cargas de trabajo, requieren que crees cuentas de servicio.
Si no usas la federación de identidades para cargas de trabajo, considera usar restricciones de política de la organización para bloquear la federación de todos los proveedores de identidad.
Haz un seguimiento de las cuentas de servicio
Con el paso del tiempo, a medida que creas más y más cuentas de servicio, quizás pierdas de vista para qué se usa cada cuenta de servicio.
El nombre comercial de una cuenta de servicio es una buena forma de capturar información adicional sobre la cuenta, como su propósito o una persona de contacto para ella. Para las cuentas de servicio nuevas, puedes propagar el nombre visible cuando creas la cuenta de servicio. Para las cuentas de servicio existentes, usa el método serviceAccounts.update() para modificar el nombre visible.
Usa cuentas de servicio con Compute Engine
Las instancias de Compute Engine necesitan ejecutarse como cuentas de servicio para tener acceso a otros recursos de Google Cloud. Para ayudar a proteger tus instancias de Compute Engine, ten en cuenta lo siguiente:
Puedes crear instancias en el mismo proyecto con cuentas de servicio diferentes. 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 conectadas, debes configurar los permisos de acceso, además de configurar los roles de IAM.
Ya que las instancias dependen de que sus cuentas de servicio tengan acceso a los recursos de Google Cloud, evita borrar cuentas de servicio mientras las instancias en ejecución aún las usen.
Para obtener más información sobre el uso de cuentas de servicio con Compute Engine, consulta Cuentas de servicio en la documentación de Compute Engine.
Identifica las cuentas de servicio sin usar
Después de un tiempo, es posible que tengas cuentas de servicio en tus proyectos que ya no uses.
Las cuentas de servicio sin usar crean un riesgo de seguridad innecesario, por lo que te recomendamos inhabilitarlas y, luego, borrarlas si estás seguro de que ya no las necesitas. Puedes usar los siguientes métodos para identificar cuentas de servicio sin usar:
- Las estadísticas de las cuentas de servicio te indican cuáles son las cuentas de servicio que no se autenticaron en tu proyecto en los últimos 90 días.
- El Analizador de actividad te permite comprobar cuándo se usó una clave o una cuenta de servicio por última vez.
También puedes usar las métricas de uso de las cuentas de servicio para realizar un seguimiento del uso de las cuentas de servicio y las claves en general.
Si eres cliente de Security Command Center Premium, puedes usar Event Threat Detection para recibir una notificación cuando una cuenta de servicio inactiva activa una acción. Las cuentas de servicio inactivas son cuentas de servicio que estuvieron inactivas durante más de 180 días. Una vez que se usa una cuenta de servicio, ya no está inactiva.
Borrar cuentas de servicio
Antes de borrar una cuenta de servicio, inhabilítala para asegurarte de que no sea necesaria. Las cuentas de servicio inhabilitadas se pueden volver a habilitar si aun están en uso.
Después de confirmar que no es necesaria una cuenta de servicio, puedes borrarla.
Vuelve a crear las cuentas de servicio borradas
Es posible borrar una cuenta de servicio y, luego, crear una cuenta de servicio nueva con el mismo nombre.
Cuando borras una cuenta de servicio, las vinculaciones de funciones no se borran de inmediato. En su lugar, las vinculaciones de funciones enumeran la cuenta de servicio con el prefijo deleted:. Si deseas ver un ejemplo, consulta Políticas con principales borrados.
Si creas una cuenta de servicio nueva con el mismo nombre que una cuenta de servicio borrada hace poco, puede que las vinculaciones anteriores todavía existan. Sin embargo, no se aplicarán a la cuenta de servicio nueva, incluso si ambas cuentas tienen la misma dirección de correo electrónico. Este comportamiento sucede porque las cuentas de servicio obtienen un ID único dentro de Identity and Access Management (IAM) en el momento de su creación. De manera interna, todas las vinculaciones de funciones se otorgan mediante estos ID, no con la dirección de correo electrónico de la cuenta de servicio. Por esta razón, cualquier vinculación de funciones que existía para una cuenta de servicio que se borró no se aplica a la cuenta de servicio nueva que usa la misma dirección de correo electrónico.
Del mismo modo, si conectas una cuenta de servicio a un recurso y, luego, borras la cuenta de servicio y creas una nueva con el mismo nombre, la cuenta nueva no estará conectada al recurso.
Para evitar este comportamiento inesperado, considera usar un nombre nuevo y único para cada cuenta de servicio. Además, si borras una cuenta de servicio por accidente, puedes intentar recuperarla, en lugar de crear una nueva.
Si no puedes recuperar la cuenta de servicio original y necesitas crear una nueva con el mismo nombre y las mismas funciones, debes otorgar las funciones a la cuenta de servicio nueva. Para obtener más información, consulta Políticas con principales borrados.
Si también necesitas que la cuenta de servicio nueva se conecte 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 conectada a la instancia para reemplazar la cuenta de servicio original por la nueva.
- En el caso de todos los demás recursos, debes borrar el recurso existente, luego, crear un recurso nuevo del mismo tipo y conectar la cuenta de servicio nueva.
¿Qué sigue?
- Descubre cómo crear cuentas de servicio.
- Obtén prácticas recomendadas para trabajar con cuentas de servicio.
- Revisa prácticas recomendadas para administrar claves de cuenta 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