Prácticas recomendadas para usar y administrar las cuentas de servicio

Las cuentas de servicio representan a usuarios que no son humanos. Se crearon para situaciones en las que una carga de trabajo, como una aplicación personalizada, necesita acceder a recursos o realizar acciones sin la participación del usuario final.

Las cuentas de servicio se diferencian de las cuentas de usuario normales de varias maneras:

  • No tienen una contraseña y no se pueden usar para el acceso basado en un navegador.
  • Se crean y administran como un recurso que pertenece a un proyecto de Google Cloud. Por el contrario, los usuarios se administran en cuentas de Cloud Identity o de Google Workspace.
  • Son específicas de Google Cloud. Por el contrario, los usuarios administrados en Cloud Identity o Google Workspace trabajan en una variedad de productos y servicios de Google.

En esta guía, se presentan prácticas recomendadas para administrar, usar y proteger las cuentas de servicio.

Elige cuándo usar las cuentas de servicio

Las cuentas de servicio se pueden usar para muchos propósitos diferentes, pero no siempre son la mejor opción. En la siguiente sección, se proporciona orientación sobre cuándo usar las cuentas de servicio y cuándo evitarlas.

Usa cuentas de servicio para situaciones sin supervisión

No todas las aplicaciones interactúan con usuarios humanos, por lo que una aplicación podría ejecutarse en segundo plano sin supervisión. Las aplicaciones sin supervisión incluyen trabajos por lotes, procesos de trabajador que despachan mensajes leídos desde una cola o un agente de supervisión de recursos.

Cada vez que una aplicación sin supervisión necesite acceder a un recurso, como un bucket de Cloud Storage, debe actuar en su propio nombre, no en nombre de ningún usuario final. Para actuar en su propio nombre, una aplicación necesita su propia identidad, que no está relacionada con ninguna identidad de usuario final.

A fin de proporcionar una aplicación con su propia identidad, crea una cuenta de servicio para esta y otorga a la cuenta de servicio acceso a los recursos a los que la aplicación necesita acceder. Si permites que una aplicación use su propia cuenta de servicio, ayudas a garantizar que la aplicación pueda funcionar sin la interacción del usuario. Además, te aseguras de que cualquier acceso a los recursos que inició la aplicación se pueda atribuir a la misma aplicación.

Usa cuentas de servicio para realizar una transición entre principales

Una aplicación que interactúa con los usuarios finales puede usar el Acceso con Google para autenticar a esos usuarios, pero no está obligada a hacerlo. En su lugar, una aplicación puede depender de un proveedor de identidad de terceros o podría implementar un esquema de autenticación personalizado para autenticar a sus usuarios.

Si una aplicación usa identidades personalizadas o de terceros y necesita acceder a un recurso, como un conjunto de datos de BigQuery o un bucket de Cloud Storage, debe realizar una transición entre principales. Debido a que las API de Google Cloud no reconocen identidades de terceros o personalizadas, la aplicación no puede propagar la identidad del usuario final a BigQuery o Cloud Storage. En cambio, la aplicación debe realizar el acceso mediante una identidad de Google diferente.

A fin de permitir que una aplicación realice una transición entre principales, crea una cuenta de servicio para la aplicación y otórgale acceso a los recursos a los que necesita acceder. Cuando la aplicación necesite acceder a un recurso de Google Cloud, asegúrate de que primero haya autenticado al usuario final y, luego, permite que use la cuenta de servicio para acceder al recurso.

Las transiciones entre principales pueden limitar la utilidad de los Registros de auditoría de Cloud de los recursos de Google Cloud afectados. Debido a que la aplicación usa una cuenta de servicio para acceder a los recursos, es posible que los Registros de auditoría de Cloud no contengan una indicación clara de si se realizó o no una acción en nombre de un usuario final en particular. A fin de garantizar que no sean repudiables, extiende tu aplicación para que escriba un registro personalizado cada vez que ocurra una transición entre principales. De esta manera, puedes hacer un seguimiento de qué usuario final activó un acceso a los recursos.

Una aplicación puede requerir acceso a datos sensibles o personales del usuario. Algunos ejemplos de esos datos incluyen el buzón o calendario de un usuario, los documentos almacenados en Drive o un conjunto de datos de BigQuery que contienen datos sensibles.

El uso de una cuenta de servicio para acceder a los datos del usuario puede ser adecuado si la aplicación realiza tareas en segundo plano sin supervisión, como indexación o escaneos de Prevención de pérdida de datos (DLP), o si el usuario final no se autenticó con una identidad de Google. En todos los demás casos en los que una aplicación actúa en nombre de un usuario final, es mejor evitar el uso de cuentas de servicio.

En lugar de usar una cuenta de servicio para acceder a los datos del usuario (posiblemente realizar una transición principal), usa el flujo de consentimiento de OAuth a fin de solicitar el consentimiento del usuario final. Luego, deja que la aplicación actúe con la identidad del usuario final. Si usas OAuth en lugar de una cuenta de servicio, ayudas a garantizar lo siguiente:

  • Los usuarios pueden revisar a qué recursos están a punto de otorgar acceso a la aplicación y pueden expresar o denegar explícitamente su consentimiento.
  • Los usuarios pueden revocar su consentimiento en su página Mi cuenta en cualquier momento.
  • No necesitas una cuenta de servicio que tenga acceso ilimitado a todos los datos del usuario.

Cuando dejas que la aplicación use credenciales de usuario final, aplazas las verificaciones de permisos en las API de Google Cloud. Este enfoque limita el riesgo de exponer accidentalmente los datos a los que el usuario no debería tener acceso debido a un error de codificación (problema de engaño de aplicación delegada).

No uses cuentas de servicio durante el desarrollo

Durante tu trabajo diario, puedes usar herramientas como la herramienta de línea de comandos de gcloud, gsutil o terraform. No uses una cuenta de servicio para ejecutar estas herramientas. En su lugar, permíteles usar primero tus credenciales mediante la ejecución de gcloud auth login (para la herramienta de gcloud y gsutil) o gcloud auth application-default login (para terraform y otras herramientas de terceros).

Puedes usar un enfoque similar para desarrollar y depurar aplicaciones que planificas implementar en Google Cloud. Una vez implementada, la aplicación puede requerir una cuenta de servicio, pero si la ejecutas en tu estación de trabajo local, puedes dejar que use tus credenciales personales.

A fin de asegurarte de que la aplicación sea compatible con las credenciales personales y las credenciales de la cuenta de servicio, usa las bibliotecas cliente de Cloud para encontrar las credenciales automáticamente.

Usa cuentas de servicio

La forma típica en que los usuarios se autentican en Google Cloud es acceder mediante un nombre de usuario y una contraseña o usar el inicio de sesión único (SSO). Las cuentas de servicio no tienen una contraseña y no pueden usar el SSO. En su lugar, las cuentas de servicio admiten un conjunto diferente de métodos de autenticación. En la siguiente sección, se proporcionan prácticas recomendadas para seleccionar un método de autenticación.

Cómo usar las cuentas de servicio

Usa cuentas de servicio conectadas cuando sea posible

Para permitir que una aplicación implementada en Google Cloud use una cuenta de servicio, conecta la cuenta de servicio con el recurso de procesamiento subyacente. Cuando conectas la cuenta de servicio, permites que la aplicación obtenga tokens para la cuenta de servicio y los use a fin de acceder a las API y los recursos de Google Cloud.

Para obtener tokens de acceso en la aplicación, usa las bibliotecas cliente si es posible. Las bibliotecas cliente detectan automáticamente si la aplicación se ejecuta en un recurso de procesamiento con una cuenta de servicio conectada.

En situaciones en las que no es práctico usar las bibliotecas cliente, ajusta la aplicación para obtener tokens del servidor de metadatos de manera programática. Entre los recursos de procesamiento que admiten el acceso al servidor de metadatos, se incluyen los siguientes:

Para obtener una lista completa de los recursos de procesamiento que te permiten conectar una cuenta de servicio, consulta Administra la suplantación de identidad de cuentas de servicio.

Usa Workload Identity para conectar cuentas de servicio a pods de Kubernetes

Si usas Google Kubernetes Engine, es posible que ejecutes una combinación de aplicaciones diferentes en un solo clúster de GKE. Es probable que las aplicaciones individuales difieran en los recursos y las API a las que necesitan acceder.

Si conectas una cuenta de servicio a un clúster de GKE o a uno de sus grupos de nodos, de forma predeterminada, todos los pods que se ejecutan en el clúster o grupo de nodos pueden actuar en nombre de la cuenta de servicio. Compartir una sola cuenta de servicio en diferentes aplicaciones dificulta la asignación del conjunto de privilegios correcto a la cuenta de servicio:

  • Si solo otorgas acceso a recursos que requieren todas las aplicaciones, es posible que algunas aplicaciones no funcionen porque carecen de acceso a ciertos recursos.
  • Si otorgas acceso a todos los recursos que necesita una aplicación específica, es posible que estés otorgando demasiado acceso.

Un mejor enfoque para administrar el acceso a los recursos en un entorno de GKE es usar Workload Identity:

  1. No conectes cuentas de servicio a los clústeres o grupos de nodos de GKE.
  2. Crea una cuenta de servicio dedicada para cada pod de Kubernetes que requiera acceso a los recursos o a las API de Google.
  3. Crea una cuenta de servicio de Kubernetes para cada pod de Kubernetes que requiera acceso a los recursos o a las API de Google, y conéctala al pod.
  4. Usa Workload Identity para crear una asignación entre las cuentas de servicio y sus cuentas de servicio de Kubernetes correspondientes.

Usa la Federación de Workload Identity para permitir que las aplicaciones que se ejecutan de forma local o en otros proveedores de servicios en la nube usen una cuenta de servicio

Si tu aplicación se ejecuta de forma local o en otro proveedor de servicios en la nube, no podrás conectar una cuenta de servicio a los recursos de procesamiento subyacentes. Sin embargo, la aplicación puede tener acceso a credenciales específicas del entorno, como las siguientes:

  • Credenciales temporales de AWS
  • Tokens de acceso de Azure Active Directory
  • Tokens de acceso de OpenID o tokens de ID emitidos por un proveedor de identidad local, como Active Directory Federation Services (AD FS) o KeyCloak

Si tu aplicación tiene acceso a una de estas credenciales y necesita acceso a los recursos o las API de Google Cloud, usa la Federación de Workload Identity.

La Federación de Workload Identity te permite crear una relación de confianza unidireccional entre un proyecto de Google Cloud y un proveedor de identidad externo. Una vez que hayas establecido la confianza, las aplicaciones podrán usar las credenciales que haya emitido el proveedor de identidad de confianza para actuar en nombre de una cuenta de servicio mediante un proceso de tres pasos:

  1. Obtén una credencial del proveedor de identidad de confianza, por ejemplo, un token de ID de OpenID Connect.
  2. Usa la API de servicio de token de seguridad (STS) para intercambiar la credencial por un token de Google STS de corta duración.
  3. Usa el token de STS a fin de autenticar en la API de Service Account Credentials de IAM y obtén tokens de acceso de Google de corta duración para una cuenta de servicio.

Mediante la Federación de Workload Identity, puedes permitir que las aplicaciones usen los mecanismos de autenticación que proporciona el entorno externo, y evitas tener que almacenar y administrar claves de cuentas de servicio.

Usa la API de credenciales de IAM para las credenciales de agente

Algunas aplicaciones solo requieren acceso a ciertos recursos en momentos específicos o en circunstancias específicas. Por ejemplo:

  • Una aplicación puede requerir acceso a los datos de configuración durante el inicio, pero puede que no lo requiera una vez que se inicialice.
  • Una aplicación de supervisión podría iniciar trabajos en segundo plano de forma periódica, en los que cada trabajo tenga diferentes requisitos de acceso.

En esas situaciones, el uso de una cuenta de servicio única y otorgarle acceso a todos los recursos implica el principio de mínimo privilegio: en cualquier momento, es probable que la aplicación tenga acceso a más recursos de los que necesita.

A fin de asegurarte de que las diferentes partes de tu aplicación solo tengan acceso a los recursos que necesitan, usa la API de credenciales de IAM para ejecutar credenciales de corta duración:

  • Crea cuentas de servicio dedicadas para cada parte de la aplicación o caso de uso, y solo otorga acceso a la cuenta de servicio a los recursos necesarios.
  • Crea otra cuenta de servicio que actúe como supervisor. Otorga a la cuenta de servicio de supervisor la función de Creador de tokens de cuenta de servicio en las otras cuentas de servicio, a fin de que pueda solicitar tokens de acceso de corta duración para estas cuentas.
  • Divide la aplicación para que una parte funcione como agente de tokens y solo permita que esta parte de la aplicación use las cuentas de servicio de supervisor.
  • Usa el agente de tokens para emitir cuentas de servicio de corta duración en las otras partes de la aplicación.

Usa las claves de las cuentas de servicio si no hay una alternativa viable

En ocasiones, es posible que no se pueda conectar una cuenta de servicio, y usar Workload Identity o la Federación de Workload Identity tampoco son opciones viables. Por ejemplo, es posible que una de tus aplicaciones locales necesite acceso a recursos de Google Cloud, pero tu proveedor de identidad local no es compatible con OpenID Connect y, por lo tanto, no se puede usar para la Federación de Workload Identity.

En situaciones en las que otros enfoques de autenticación no sean viables, crea una clave de cuenta de servicio para la aplicación. Una clave de cuenta de servicio permite que una aplicación se autentique como una cuenta de servicio, de manera similar a como un usuario podría autenticarse con un nombre de usuario y contraseña. Las claves de cuenta de servicio son un tipo de Secret y deben protegerse del acceso no autorizado. Es mejor almacenarlas en una ubicación segura, como un Key Vault, y rotarlas con frecuencia.

Administra cuentas de servicio

Las cuentas de servicio difieren de las cuentas de usuario normales, no solo en cómo se usan, sino también en cómo deben administrarse. En las siguientes secciones, se proporcionan prácticas recomendadas para administrar cuentas de servicio.

Administra cuentas de servicio como recursos

Las cuentas de usuario normales, por lo general, se administran de acuerdo con los procesos joiner-mover-leaver de una organización: cuando se une un empleado, se crea una nueva cuenta de usuario para él. Cuando se cambia de departamento, su cuenta de usuario se actualiza. Y cuando abandona la empresa, su cuenta de usuario se suspende o borra.

Por el contrario, las cuentas de servicio no están asociadas con ningún empleado en particular. En su lugar, es mejor pensar en las cuentas de servicio como recursos que pertenecen a otro recurso (o forman parte de él), como una instancia de VM específica o una aplicación.

Para administrar las cuentas de servicio de manera eficaz, no las consideres de forma aislada. Por el contrario, considéralas en el contexto del recurso con el que están asociadas y administra la cuenta de servicio y su recurso asociado como una unidad: aplica los mismos procesos, el mismo ciclo de vida y la misma diligencia a la cuenta de servicio y su recurso asociado, y usa las mismas herramientas para administrarlas.

Crea cuentas de servicio de un solo propósito

Compartir una sola cuenta de servicio en varias aplicaciones puede complicar la administración de la cuenta:

  • Las aplicaciones podrían tener ciclos de vida diferentes. Si una aplicación se retira del servicio, es posible que no esté claro si la cuenta de servicio también se puede retirar o si aún es necesaria.
  • Con el tiempo, los requisitos de acceso de las aplicaciones podrían diferir. Si las aplicaciones usan la misma cuenta de servicio, es posible que debas otorgar acceso a la cuenta de servicio a una mayor cantidad de recursos, lo que, a su vez, aumenta el riesgo general.
  • Los Registros de auditoría de Cloud incluyen el nombre de la cuenta de servicio que realizó un cambio o accedió a los datos, pero no muestran el nombre de la aplicación que usó la cuenta de servicio. Si varias aplicaciones comparten una cuenta de servicio, es posible que no puedas hacer seguimiento de la actividad hasta la aplicación correcta.

A fin de evitar estas complicaciones, crea cuentas de servicio dedicadas para cada aplicación y evita usar cuentas de servicio predeterminadas.

Sigue una convención de nombres y documentación

Para facilitar el seguimiento de la asociación entre un servicio y una aplicación o recurso, sigue una convención de nombres cuando crees cuentas de servicio nuevas:

  • Agrega un prefijo a la dirección de correo electrónico de la cuenta de servicio que identifique cómo se usa la cuenta. Por ejemplo:
    • vm- para las cuentas de servicio conectadas a una instancia de VM
    • wi- para las cuentas de servicio que usa Workload Identity
    • wif- para las cuentas de servicio que usa la Federación de Workload Identity
    • onprem- para las cuentas de servicio que usan las aplicaciones locales
  • Incorpora el nombre de la aplicación en la dirección de correo electrónico de la cuenta de servicio, por ejemplo: vm-travelexpenses@ si la VM ejecuta una aplicación de gastos de viaje.
  • Usa el campo de descripción para agregar una persona de contacto, vínculos a la documentación relevante y otras notas.

No incorpores información sensible ni condiciones en la dirección de correo electrónico de una cuenta de servicio.

Identifica y, luego, inhabilita cuentas de servicio sin usar

Cuando ya no se use una cuenta de servicio, inhabilítala. Cuando inhabilitas las cuentas de servicio sin usar, reduces el riesgo de que estas se usen de forma inadecuada para el movimiento lateral o para la elevación de privilegios por parte de una persona o entidad que actúa de mala fe.

En el caso de las cuentas de servicio de un solo propósito asociadas con un recurso específico, como una instancia de VM, inhabilita la cuenta de servicio apenas se inhabilite o se borre el recurso asociado.

Para las cuentas de servicio que se usan con varios propósitos o se comparten entre varios recursos, puede ser más difícil identificar si la cuenta de servicio aún se utiliza. En estos casos, usa los siguientes métodos:

Inhabilita las cuentas de servicio que no se usen antes de borrarlas

Si borras una cuenta de servicio y, luego, creas una nueva con el mismo nombre, se asignará una identidad diferente a la cuenta de servicio nueva. Como resultado, ninguna de las vinculaciones de IAM originales se aplica a la cuenta de servicio nueva. Por el contrario, si inhabilitas y vuelves a habilitar una cuenta de servicio, todas las vinculaciones de IAM permanecen intactas.

A fin de evitar perder de forma involuntaria las vinculaciones de IAM, es mejor no borrar cuentas de servicio de inmediato. En su lugar, inhabilita una cuenta de servicio si ya no es necesaria y solo bórrala una vez transcurrido cierto período.

Nunca borres las cuentas de servicio predeterminadas, como la cuenta de servicio predeterminada de App Engine o de Compute Engine. Estas cuentas de servicio no se pueden volver a crear sin inhabilitar y volver a habilitar la API respectiva, lo que puede interrumpir la implementación existente. Si no usas las cuentas de servicio predeterminadas, inhabilítalas.

¿Qué sigue?