Cuentas de servicio

En esta página, se explican las cuentas de servicio, los tipos de cuentas de servicio y las funciones de IAM disponibles para las cuentas de servicio.

Antes de comenzar

  • Comprende los conceptos básicos de IAM.

¿Qué son las cuentas de servicio?

Una cuenta de servicio es un tipo especial de cuenta que usa una aplicación o carga de trabajo de procesamiento, como una instancia de máquina virtual (VM) de Compute Engine, en lugar de una persona. Las aplicaciones usan cuentas de servicio para realizar 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.

Por ejemplo, una VM de Compute Engine puede ejecutarse como una cuenta de servicio, y esa cuenta puede obtener permisos para acceder a los recursos que necesita. De esta forma, la cuenta de servicio es la identidad del servicio y los permisos de la cuenta de servicio controlan los recursos a los que tiene acceso el servicio.

Una cuenta de servicio se identifica por su dirección de correo electrónico, que es única a la cuenta.

Diferencias entre una cuenta de servicio y una cuenta de usuario

Las cuentas de servicio difieren de las cuentas de usuario en algunos aspectos clave:

  • Las cuentas de servicio no tienen contraseñas y no pueden acceder a través de navegadores ni cookies.
  • Las cuentas de servicio están asociadas con pares de claves RSA públicas/privadas que se usan para la autenticación en Google y para la firma de datos.
  • Puedes permitir que otros usuarios o cuentas de servicio actúen en nombre de una cuenta de servicio.
  • 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.

Impide la creación de cuentas de servicio

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:

Cuentas de servicio y Grupos de Google

Puedes agregar cuentas de servicio a un Grupo de Google y, luego, otorgar funciones 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.

Tipos de claves para cuentas de servicio

Cada cuenta de servicio está asociada con un par de clave RSA pública/privada. La API de credenciales de la cuenta de servicio usa este par de claves internas a fin de crear credenciales de cuenta de servicio de corta duración y para firmar BLOB y tokens web JSON (JWT). Este par de claves se conoce como el par de claves administradas por Google.

Además, puedes crear varios pares de claves RSA públicas/privadas, conocidas como pares de claves administradas por el usuario, y usar la clave privada para autenticarte con las API de Google. Esta clave privada se conoce como clave de cuenta de servicio.

Pares de claves administradas por Google

La API de credenciales de la cuenta de servicio usa los pares de claves administradas por Google y los servicios de Google Cloud, como App Engine y Compute Engine, a fin de generar credenciales de corta duración para cuentas de servicio.

Los pares de claves administradas por Google se rotan y usan de forma automática para firmar por un máximo de dos semanas. El proceso de rotación es probabilístico. El uso de la clave nueva aumentará y disminuirá de manera gradual durante el ciclo de vida de la clave.

La clave privada en un par de claves administradas por Google siempre se mantiene guardada y nunca puedes acceder a ella directamente.

La clave pública en un par de claves administradas por Google es de acceso público, de modo que cualquiera pueda verificar las firmas que se crean con la clave privada. Puedes acceder a la clave pública en varios formatos diferentes:

  • X.509 certificate: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • Clave web JSON (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • Formato sin procesar: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Si descargas la clave pública y la almacenas en caché, te recomendamos almacenarla en caché por un máximo de 24 horas a fin de asegurarte de que siempre tengas la clave actual. Independientemente de cuándo recuperes la clave pública, será válida durante al menos 24 horas después de recuperarla.

Pares de claves administradas por el usuario

Puedes crear pares de claves administradas por el usuario para una cuenta de servicio y, luego, usar la clave privada de cada par de claves a fin de autenticarte con las API de Google. Esta clave privada se conoce como clave de cuenta de servicio. Cada cuenta de servicio puede tener hasta 10 claves de cuentas de servicio. Google almacena solo la parte pública de un par de claves administradas por el usuario.

Existen dos maneras de crear un par de claves administradas por el usuario para una cuenta de servicio:

Las claves administradas por el usuario son credenciales muy potentes y pueden representar un riesgo de seguridad si no se administran de forma adecuada. Para limitar el uso de claves administradas por el usuario, puedes aplicar las siguientes restricciones de políticas de la organización a una organización, un proyecto o una carpeta:

  • constraints/iam.disableServiceAccountKeyCreation: Evita que las principales creen claves de cuenta de servicio administradas por el usuario.
  • constraints/iam.disableServiceAccountKeyUpload: Evita que las principales suban una clave pública para una cuenta de servicio.

Si aplicas estas restricciones porque usas la federación de Workload Identity, considera usar las restricciones de las políticas de la organización para la federación de Workload Identity a fin de especificar qué proveedores de identidad están permitidos.

Tipos de cuentas de servicio

Cuentas de servicio administradas por el usuario

Puedes crear cuentas de servicio administradas por el usuario en tu proyecto con la API de IAM, Cloud Console o la herramienta de línea de comandos de gcloud. Eres responsable de administrar y proteger estas cuentas.

De forma predeterminada, puedes crear hasta 100 cuentas de servicio administradas por el usuario en un proyecto. Si esta cuota no satisface tus necesidades, puedes usar Cloud Console para solicitar un aumento de cuota. Las cuentas de servicio predeterminadas que se describen en esta página no se consideran para esta cuota.

Cuando creas una cuenta de servicio administrada por el usuario en tu proyecto, debes elegir un nombre para esta. Este nombre aparecerá en la dirección de correo electrónico que identifica a la cuenta de servicio, en el que se usa el siguiente formato:

service-account-name@project-id.iam.gserviceaccount.com

Cuentas de servicio predeterminadas

Cuando habilitas o usas algunos servicios de Google Cloud, se crean cuentas de servicio administradas por el usuario que permiten que el servicio implemente trabajos que acceden a otros recursos de Google Cloud. Estas cuentas se conocen como cuentas de servicio predeterminadas.

Si tu aplicación se ejecuta en un entorno de Google Cloud que tiene una cuenta de servicio predeterminada, puede usar las credenciales para que la cuenta de servicio predeterminada llame a las API de Google Cloud. De forma alternativa, puedes crear tu propia cuenta de servicio administrada por el usuario y usarla para autenticar. Para obtener más información, consulta Encuentra credenciales de forma automática.

En la siguiente tabla, se enumeran los servicios que crean cuentas de servicio predeterminadas:

Servicio Nombre de la cuenta de servicio Dirección de correo electrónico
App Engine y cualquier servicio de Google Cloud que use App Engine Cuenta de servicio predeterminada de App Engine project-id@appspot.gserviceaccount.com
Compute Engine y cualquier servicio de Google Cloud que use Compute Engine Cuenta de servicio predeterminada de Compute Engine project-number-compute@developer.gserviceaccount.com

Cuentas de servicio administradas por Google

Algunos servicios de Google Cloud necesitan acceso a tus recursos para actuar en tu nombre. Por ejemplo, cuando usas Cloud Run para ejecutar un contenedor, el servicio necesita acceder a cualquier tema de Pub/Sub que pueda activarlo.

A fin de satisfacer esta necesidad, Google crea y administra cuentas de servicio para muchos servicios de Google Cloud. Estas cuentas de servicio se conocen como cuentas de servicio administradas por Google. Es posible que veas cuentas de servicio administradas por Google en la política de IAM de tu proyecto, en los registros de auditoría o en la página de IAM en Cloud Console.

Las cuentas de servicio administradas por Google no se enumeran en la página Cuentas de servicio en Cloud Console.

Por ejemplo:

  • Agente de servicio de las API de Google Es probable que el proyecto contenga una cuenta de servicio llamada Agente de servicio de las API de Google, con una dirección de correo electrónico que use el siguiente formato: project-number@cloudservices.gserviceaccount.com

    Esta cuenta de servicio ejecuta procesos internos de Google en tu nombre. Se le otorga de forma automática la función de editor (roles/editor) en el proyecto.

  • Administrador de funciones para cuentas de servicio administradas por Google. Tus registros de auditoría para IAM pueden hacer referencia a la cuenta de servicio service-agent-manager@system.gserviceaccount.com.

    Esta cuenta de servicio administra las funciones que se otorgan a otras cuentas de servicio administradas por Google. Solo se puede ver en los registros de auditoría.

    Por ejemplo, si usas una API nueva, Google puede crear de forma automática una cuenta de servicio administrada por Google nueva y otorgar funciones a la cuenta de servicio en el proyecto. Si otorgas estas funciones, se genera una entrada de registro de auditoría, que muestra que service-agent-manager@system.gserviceaccount.com estableció la política de IAM para el proyecto.

  • Otras cuentas de servicio administradas por Google. Tu proyecto puede contener otras cuentas de servicio administradas por Google que actúan en nombre de servicios individuales. Estas cuentas de servicio se suelen denominar agentes de servicio. Es posible que se otorguen funciones automáticamente a los agentes de servicio. Los nombres de tales funciones suelen terminar en serviceAgent.

    Para ver una lista completa de los agentes de servicio y las funciones que se otorgan automáticamente a cada uno de ellos, consulta Agentes de servicio.

Ubicaciones de la cuenta 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 comenzar a usar las cuentas de servicio. Sin embargo, puede ser difícil realizar 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-accounts y una instancia de Cloud SQL en el proyecto my-application, debes habilitar la API de Cloud SQL en ambos my-service-accounts y my-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.

Permisos de las cuentas de servicio

Las cuentas de servicio son identidades y recursos.

Debido a que las cuentas de servicio son identidades, puedes permitir que una cuenta de servicio acceda a los recursos de tu proyecto si le otorgas una función, 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 la función de visualizador de objetos de almacenamiento (roles/storage.objectViewer) en el bucket.

Sin embargo, las cuentas de servicio también son recursos que aceptan políticas de IAM. Como resultado, puedes permitir que otras principales accedan a una cuenta de servicio si les otorgas una función en la cuenta de servicio o en uno de los recursos principales de la cuenta de servicio. Por ejemplo, para permitir que un usuario robe la identidad de una cuenta de servicio, puedes otorgarle al usuario la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser) en esta.

Para obtener más información sobre cómo otorgar funciones a las principales, incluidas las cuentas de servicio, consulta Cómo otorgar, cambiar y revocar el acceso a los recursos.

Para obtener más información sobre cómo otorgar funciones en cuentas de servicio, consulta Administra el robo de identidad de cuentas de servicio.

La función de usuario de cuenta de servicio

Puedes otorgar la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser) a nivel de proyecto a todas las cuentas de servicio del proyecto, o a nivel de cuenta de servicio.

  • Si se otorga la función de usuario de cuenta de servicio a un usuario para un proyecto, este tendrá acceso a todas las cuentas de servicio del proyecto, incluidas las cuentas de servicio que se creen en el futuro.

  • Otorgar la función de usuario de cuenta de servicio a un usuario para una cuenta de servicio específica solo le otorga a un usuario acceso a esa cuenta de servicio.

Los usuarios que tengan la función de usuario de cuenta de servicio en una cuenta de servicio pueden usarla para acceder de forma indirecta a todos los recursos a los que tiene acceso la cuenta de servicio. Por ejemplo, si una cuenta de servicio tiene la función de administrador de Compute (roles/compute.admin), un usuario que tiene la función de usuarios de cuenta de servicio (roles/iam.serviceAccountUser) en esa cuenta de servicio puede actuar como la cuenta de servicio para iniciar una instancia de Compute Engine. En este flujo, el usuario actúa en nombre de la cuenta de servicio para realizar cualquier tarea con sus funciones y permisos otorgados.

Para obtener más información sobre cómo otorgar funciones a los usuarios en cuentas de servicio, consulta Administra la suplantación de identidad de cuentas 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 externas privadas para esas cuentas de servicio. Las siguientes son prácticas recomendadas 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 externas, bórralas.
  • Si los usuarios no necesitan permiso para administrar o usar cuentas de servicio, quítalos de la política de IAM 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.

Para obtener más información sobre las recomendaciones, consulta Comprende las cuentas de servicio.

La función creador del token de la cuenta de servicio

Esta función permite actuar en nombre de cuentas de servicio para crear tokens de acceso OAuth2, firmar BLOB o JWT.

Permisos de acceso

Los permisos de acceso son un método heredado para especificar los permisos de una instancia de máquina virtual (VM) de Compute Engine. Definen los permisos de OAuth predeterminados que se usan en las solicitudes de la herramienta de gcloud y las bibliotecas cliente.

Google Cloud ahora usa IAM, no permisos de acceso, a fin de especificar los permisos para las instancias de Compute Engine. Sin embargo, aún debes establecer un permiso de acceso cuando configuras una instancia para actuar en nombre de una cuenta de servicio.

Si quieres obtener más información, consulta la documentación de Compute Engine.

Credenciales de cuentas de servicio de corta duración

Puedes crear credenciales de corta duración que te permitan asumir la identidad de una cuenta de servicio de Google Cloud. Estas credenciales se pueden usar para autenticar las llamadas a la API de Google Cloud o a otras API que no sean de Google.

El caso práctico más común para estas credenciales es delegar de forma temporal el acceso a los recursos de Google Cloud en diferentes proyectos, organizaciones o cuentas. Por ejemplo, en lugar de proporcionarle a un emisor externo credenciales permanentes de una cuenta de servicio con muchos privilegios, se le puede otorgar un acceso temporal de emergencia. Como alternativa, un emisor externo puede actuar en nombre de una cuenta de servicio designada con menos permisos sin necesidad de tener las credenciales de una cuenta de servicio con más privilegios.

A fin de obtener más información, consulta la sección sobre cómo crear credenciales de cuentas de servicio de corta duración.

Federación de Workload Identity

Puedes otorgar identidades a partir de una carga de trabajo que se ejecuta fuera de Google Cloud, como en Amazon Web Services (AWS) o Microsoft Azure, para brindarles la capacidad de actuar como cuentas de servicio. Esto te permite acceder a los recursos directamente mediante el uso de credenciales de corta duración, en lugar de usar una clave de cuenta de servicio.

Para obtener más información, consulta Federación de Workload Identity.

Credencial predeterminada de la aplicación

Las credenciales predeterminadas de la aplicación son una herramienta que usan las bibliotecas cliente de Google Cloud para descubrir de forma automática las credenciales de la cuenta de servicio. Puedes especificar una clave de cuenta de servicio en una variable de entorno, y las credenciales predeterminadas de la aplicación usan esa clave de cuenta de servicio de forma automática. Si no especificas una clave, las credenciales predeterminadas de la aplicación usan la cuenta de servicio adjunta al recurso que ejecuta tu código o la cuenta de servicio predeterminada para el servicio que ejecuta tu código.

Para obtener más información, consulta Busca credenciales automáticamente.

¿Qué sigue?

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