Comprender las cuentas de servicio

Información general

Una cuenta de servicio es un tipo de Cuenta de Google especial que representa a un usuario no humano. Estas cuentas deben autenticarse y tener autorización para acceder a los datos de las API de Google.

Por lo general, las cuentas de servicio se usan en las siguientes situaciones:

  • Ejecución de cargas de trabajo en máquinas virtuales (VM)
  • Ejecución de cargas de trabajo en estaciones de trabajo locales o en centros de datos que llaman a las API de Google
  • Ejecución de cargas de trabajo que no están vinculadas al ciclo de vida de un usuario humano

Tu aplicación toma la identidad de la cuenta de servicio para llamar a las API de Google a fin de que los usuarios no se involucren directamente.

Administrar cuentas de servicio

Una vez que hayas decidido que necesitas una cuenta de servicio, puedes hacerte las siguientes preguntas para comprender cómo la usarás:

  • ¿A qué recursos puede acceder la cuenta de servicio?
  • ¿Qué permisos necesita la cuenta de servicio?
  • ¿Dónde se ejecutará el código que toma la identidad de la cuenta de servicio: en Google Cloud Platform o de forma local?

Usa el siguiente diagrama de flujo para descubrir las respuestas a las preguntas antes mencionadas:

Diagrama de flujo de la cuenta de servicio

Ten en cuenta que las cuentas de servicio pueden considerarse tanto un recurso como una identidad.

Cuando una cuenta de servicio se considera una identidad, se le puede otorgar una función, lo que le permite acceder a un recurso (como un proyecto).

Cuando una cuenta de servicio se considera un recurso, se les pueden otorgar funciones a otros usuarios para que accedan o administren esa cuenta de servicio.

Otorgar acceso a las cuentas de servicio

Otorgarle acceso a una cuenta de servicio a un recurso es similar a otorgarle acceso a cualquier otra identidad. Por ejemplo, si ejecutas una aplicación en Google Compute Engine y deseas que solo acceda a crear objetos en Google Cloud Storage. Puedes crear una cuenta de servicio para la aplicación y otorgarle la función de creador de objetos de almacenamiento. En el siguiente diagrama, se ilustra este ejemplo:

Diagrama de flujo de la cuenta de servicio

Consulta Otorga funciones a todos los tipos de miembros, que incluye las cuentas de servicio.

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 visible de una cuenta de servicio es una buena forma de obtener información adicional sobre la cuenta de servicio, 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() a fin de modificar el nombre visible.

Borrar y volver a crear cuentas de servicio

Es posible borrar una cuenta de servicio y luego crear una cuenta de servicio nueva con el mismo nombre. Usar el nombre de una cuenta de servicio que se borró podría ocasionar un comportamiento inesperado.

Cuando borras una cuenta de servicio, las vinculaciones de funciones no se borran de inmediato. Si creas una cuenta de servicio nueva con el mismo nombre de una cuenta de servicio borrada hace poco, las vinculaciones anteriores todavía podrían existir. 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 IAM en el momento de su creación. De manera interna, todas las vinculaciones de funciones se otorgan mediante estos ID y 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 nueva cuenta de servicio que usa la misma dirección de correo electrónico.

A fin de 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 recuperar la cuenta de servicio 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, sigue estos pasos:

  1. Crea la cuenta de servicio nueva.
  2. Para cada recurso al que tenga que acceder la cuenta de servicio nueva, revoca todas las funciones que se le otorgaron a la cuenta de servicio original para ese recurso.

  3. Después de revocar las funciones de la cuenta de servicio original, asigna las funciones a la cuenta de servicio nueva.

Permisos para cuentas de servicio

En esta sección, se describen situaciones comunes de los permisos otorgados a cuentas de servicio o cuentas de usuario que cuentan con los permisos para actuar como cuentas de servicio:

Otorga permisos mínimos a las cuentas de servicio

Al igual que con todos los tipos de miembros, solo debes otorgar a la cuenta de servicio el conjunto de permisos mínimos necesarios para que logre su objetivo. Consulta Otorga funciones a todos los tipos de miembros, que incluye las cuentas de servicio.

Cuando les otorgas permisos a los usuarios a fin de que accedan a una cuenta de servicio, ten en cuenta que ese usuario puede acceder a todos los recursos para los que esa cuenta de servicio tiene permisos. Por lo tanto, es importante que configures los permisos de tus cuentas de servicio con cuidado. Es decir, debes ser estricto con respecto a los usuarios de tu equipo que pueden usar cuentas de servicio (o actuar como una).

Los usuarios con funciones de IAM para actualizar las instancias de App Engine y Compute Engine (como el implementador de App Engine o el administrador de instancias de Compute) pueden ejecutar código de manera efectiva como las cuentas de servicio que se usan a fin de ejecutar estas instancias y, de forma indirecta, obtener acceso a todos los recursos a los que tienen acceso las cuentas de servicio. De manera similar, el acceso SSH a una instancia de Compute Engine puede proporcionar la capacidad de ejecutar código como esa instancia.

Permisos de cuentas de servicio para situaciones comunes

Las cuentas de servicio se pueden usar en muchas situaciones diferentes, y cada una de ellas requiere permisos específicos. En esta sección, se describen situaciones comunes y los permisos necesarios.

Iniciar trabajos de larga duración

Permisos:

  • iam.serviceAccounts.actAs

Funciones:

  • roles/editor (Editor)
  • roles/iam.serviceAccountUser (Usuario de cuenta de servicio)

Un usuario (o servicio) puede vincular una cuenta de servicio a un servicio de trabajos de larga duración. A continuación, se muestran algunos ejemplos:

  • VM de Compute Engine
  • App de App Engine
  • Función de Cloud Functions
  • Trabajo de Dataflow

En este caso, el usuario debe contar con el permiso para implementar el trabajo, que varía según el servicio, y el permiso para actuar como la cuenta de servicio, que se otorga mediante iam.serviceAccounts.actAs en la cuenta de servicio. Ten en cuenta que recibir solo el permiso iam.serviceAccounts.actAs no le permite al usuario actuar como la cuenta de servicio.

Una vez que se haya otorgado el permiso iam.serviceAccounts.actAs en la cuenta de servicio, el usuario podrá iniciar un trabajo de larga duración que se ejecute como la cuenta de servicio. Cuando el trabajo se haya iniciado, ese usuario ya no necesitará conservar el acceso a la cuenta de servicio. El trabajo seguirá ejecutándose incluso si ese usuario pierde el acceso. El servicio de trabajos continúa usando sus propios permisos en la cuenta de servicio para mantener el trabajo en ejecución con la identidad de esa cuenta de servicio.

Ten en cuenta que, a veces, es necesario tener el permiso iam.serviceAccounts.actAs para cambiar un trabajo de larga duración (como configurar los metadatos de la instancia en una VM de Compute Engine).

Si deseas obtener más información sobre este flujo, consulta Crea y habilita cuentas de servicio para instancias en la documentación de Compute Engine.

Actuar directamente como una cuenta de servicio

Permisos:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation

Funciones:

  • roles/iam.serviceAccountTokenCreator (Creador de tokens de cuenta de servicio)

Una vez que se le otorgan los permisos necesarios, un usuario (o servicio) puede actuar directamente como una cuenta de servicio (o confirmar la identidad de esta) en algunas situaciones comunes.

En primer lugar, el usuario puede obtener credenciales a corto plazo para la cuenta de servicio mediante el permiso iam.serviceAccounts.getAccessToken y a través de una llamada al método generateAccessToken(). Mediante el uso de credenciales a corto plazo, un usuario puede ejecutar comandos en Google Cloud y acceder a todos los recursos a los que tiene acceso la cuenta de servicio. Por ejemplo, este flujo permite que un usuario emplee la marca gcloud --impersonate-service-account para actuar como la cuenta de servicio sin que se requiera el uso de una clave de cuenta de servicio externa descargada.

En segundo lugar, el usuario puede obtener artefactos firmados por la clave privada administrada por Google de la cuenta de servicio mediante el permiso iam.serviceAccounts.signBlob y a través de una llamada a los métodos signBlob() o signJwt(). La clave privada administrada por Google siempre se mantiene guardada y nunca se expone directamente. signBlob() permite la firma de cargas útiles arbitrarias (como URL firmadas por Cloud Storage), mientras que signJwt() solo permite firmar JWT con el formato correcto.

Por último, el usuario puede actuar como la cuenta de servicio (o confirmarla) sin tener que recuperar una credencial para la cuenta de servicio. Este es un caso práctico avanzado y solo se admite para el acceso programático mediante el método generateAccessToken(). En situaciones con al menos 3 cuentas de servicio, como A, B y C, la cuenta de servicio A puede obtener un token de acceso para la cuenta de servicio C si a la cuenta de servicio A se le otorga el permiso iam.serviceAccounts.implicitDelegation en B y B recibe el permiso iam.serviceAccounts.getAccessToken en C.

Generar tokens de ID de OpenID Connect (OIDC)

Permisos:

  • iam.serviceAccounts.getOpenIdToken

Funciones:

  • roles/iam.serviceAccountTokenCreator (Creador de tokens de cuenta de servicio)

Un usuario (o 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 que tiene el permiso iam.serviceAccounts.getOpenIdToken.

La mayoría de las API de Google no aceptan directamente estos tokens sin que tu organización implemente una federación de identidades adicional para otorgar acceso a Google. Existen algunas excepciones, como Identity-Aware Proxy, que permite el acceso basado en OIDC a aplicaciones ejecutadas por el usuario.

Generar claves privadas externas

Permisos:

  • iam.serviceAccountKeys.create

Funciones:

  • roles/editor (Editor)
  • roles/iam.serviceAccountAdmin (Administrador de cuenta de servicio)

Un usuario o servicio puede generar material de la clave privada externa (RSA) que se puede usar para autenticarse directamente en Google como la cuenta de servicio. Este material de la 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 la clave privada debe tratarse con mucho cuidado y debe considerarse menos seguro cuanto más tiempo exista. Por lo tanto, rotar el material de la clave privada es fundamental para mantener una seguridad sólida.

Administrar claves de cuenta de servicio

Existen dos tipos de claves de cuenta de servicio:

  • Claves administradas por GCP. Los servicios de Cloud Platform como App Engine y Compute Engine usan estas claves. No pueden descargarse y se rotan y usan de forma automática para acceder por un máximo de hasta dos semanas. El proceso de rotación es probabilístico. El uso de la nueva clave mejorará y empeorará de manera gradual durante el ciclo de vida de la clave. Recomendamos almacenar en la caché la clave pública configurada para la cuenta de servicio por lo menos por 24 horas a fin de asegurarte de que siempre tendrás acceso a la clave actual.

  • Claves administradas por el usuario. El usuario puede crear, descargar y administrar estas claves. Después de borrarlas de la cuenta de servicio, no puedes usarlas para la autenticación.

Para las claves administradas por el usuario, debes asegurarte de que tienes procesos configurados a fin de cumplir con los requisitos de administración de claves como los siguientes:

  • Almacenamiento de claves
  • Distribución de claves
  • Revocación de claves
  • Rotación de claves
  • Protección de claves contra usuarios no autorizados
  • Recuperación de claves

Cualquier persona que tenga acceso a una clave privada válida para una cuenta de servicio podrá acceder a los recursos a través de la cuenta de servicio. Ten en cuenta que el ciclo de vida del acceso de la clave a la cuenta de servicio (y, por lo tanto, a los datos a los que tiene acceso la cuenta de servicio) es independiente del ciclo de vida del usuario que descargó la clave.

Siempre desaconseja a los desarrolladores que ingresen las claves en el código fuente o que las dejen en el directorio de descargas de su estación de trabajo.

Para mejorar la seguridad de las claves, sigue las siguientes pautas:

Usar cuentas de servicio con Compute Engine

Las instancias de Compute Engine necesitan ejecutarse como cuentas de servicio para tener acceso a otros recursos de Cloud Platform. Para asegurarte de que tus instancias de Compute Engine sean seguras, ten en cuenta lo siguiente:

  • Puedes crear VM en el mismo proyecto con cuentas de servicio diferentes. Para cambiar la cuenta de servicio de una VM después de crearla, usa el método instances.setServiceAccount.

  • Puedes otorgar funciones de IAM a cuentas de servicio para definir a qué tienen acceso. En muchos casos, ya no deberás depender de los alcances. Esto te da la ventaja de modificar los permisos de una cuenta de servicio de una VM sin recrear la instancia.

  • Ya que las instancias dependen de que sus cuentas de servicio tengan acceso a los recursos de Cloud Platform, evita borrar cuentas de servicio cuando todavía las usan instancias en ejecución. Si borras cuentas de servicio, las instancias pueden empezar a fallar en sus operaciones.

Prácticas recomendadas

  • Especifica quién puede actuar como cuenta de servicio. Los usuarios que son usuarios de cuenta de servicio para una cuenta de servicio pueden acceder, de forma indirecta, a todos los recursos a los que tiene acceso la cuenta de servicio. Por lo tanto, ten cuidado cuando otorgas la función serviceAccountUser a un usuario.

  • Otórgale a la cuenta de servicio solo los permisos mínimos necesarios para que logre su objetivo. Consulta Otorga funciones a todos los tipos de miembros, que incluye las cuentas de servicio.

  • Crea cuentas de servicio para cada servicio solo con los permisos requeridos.

  • Usa el nombre comercial de una cuenta de servicio para realizar un seguimiento de las cuentas de servicio. Cuando crees una cuenta de servicio, propaga el nombre comercial con el propósito de esa cuenta de servicio.

  • Define una convención para nombrar tus cuentas de servicio.

  • Implementa procesos para automatizar la rotación de las claves de cuentas de servicio administradas por el usuario.

  • Aprovecha la API de la cuenta de servicio de IAM para implementar la rotación de claves.

  • Controla las cuentas de servicio y las claves mediante el método serviceAccount.keys.list() o la página Visualizador de registros en la consola.

  • No borres cuentas de servicio que estén ejecutando instancias en App Engine o Compute Engine, a menos que desees que esas aplicaciones pierdan el acceso a la cuenta de servicio.