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

Para obtener más información, consulta Asigna funciones a cuentas de servicio.

Actuar como una cuenta de servicio

Existen tres maneras en las que puedes actuar como una cuenta de servicio para acceder a las API de Google:

  • Realizar una autenticación mediante claves privadas de RSA
  • Obtener autorización mediante políticas de Cloud IAM
  • Realizar una implementación de trabajos en servicios de Google Cloud

Realizar una autenticación mediante claves privadas de RSA

Todas las cuentas de servicio cuentan con pares de claves administradas por Google Cloud que se rotan con regularidad, y la plataforma mantiene las claves privadas guardadas, de modo que no se pueda acceder a ellas directamente.

También es posible crear de forma manual un par de claves administradas por el usuario. Google Cloud generará la clave privada y la pública, almacenará la clave pública y proporcionará la clave privada al usuario. El par de claves no podrá autenticarse en Google cuando se borre de la cuenta de servicio.

Obtén autorización mediante políticas de Cloud IAM

Todas las cuentas de servicio tienen políticas de Cloud IAM que otorgan acceso a la cuenta de servicio. Con algunos de estos permisos, los usuarios pueden actuar como la cuenta de servicio o convertirse en ella, según las credenciales con las que cuenten.

Implementar trabajos en Google Cloud

Algunos servicios de Google Cloud, como Compute Engine, App Engine o Cloud Functions, te permiten implementar un trabajo (como una VM o una función) que se ejecuta como la identidad de una cuenta de servicio.

A fin de implementar trabajos de esta manera, la cuenta de servicio debe tener los permisos necesarios para el servicio deseado y la cuenta de usuario también debe tener el permiso iam.serviceAccounts.actAs en la cuenta de servicio. Este permiso se incluye en la función de usuario de cuenta de servicio. También es necesario que el servicio de Google Cloud mantenga los permisos de Cloud IAM en la cuenta de servicio, lo que, por lo general, se realiza de forma automática.

Ejemplos

Ejecutar una VM con una cuenta de servicio

Supongamos que tienes un trabajo de larga duración y que tus empleados tienen permiso para iniciarlo. No sería conveniente que ese trabajo se dé por finalizado cuando el último empleado que lo inició se vaya de la empresa.

Este problema se solucionaría con la creación de una cuenta de servicio para iniciar y detener el trabajo. Puedes hacerlo con los siguientes pasos:

  1. Crea una cuenta de servicio.

  2. Otorga la función de usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la cuenta de servicio a los empleados que necesitan permiso para iniciar el trabajo. En este caso, la cuenta de servicio se trata como un recurso.

  3. Otorga la función de administrador de instancias de Compute (roles/compute.instanceAdmin.v1) a los mismos empleados.

  4. Ahora, los empleados pueden crear instancias de Compute Engine que administran la cuenta de servicio, se conectan a ella y usan la cuenta de servicio para empezar el trabajo. Por ejemplo:

    gcloud compute instances create my-instance --scopes=cloud-platform \
    --service-account=my-service-account@test9q.iam.gserviceaccount.com \
    --zone=us-central1-a
    

Migrar datos a Google Cloud

Supongamos que procesas datos en otro proveedor de servicios en la nube y quieres transferir los datos procesados a Google Cloud Platform. Puedes usar la cuenta de servicio desde las máquinas virtuales en la nube externa para enviar los datos a Google Cloud Platform. Para hacer esto, debes crear y descargar una clave de cuenta de servicio cuando creas la cuenta de servicio y luego usar esa clave desde el proceso externo para llamar a las API de Cloud Platform.

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 Cloud 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:

Otorgar permisos mínimos a las cuentas de servicio

Solo debes otorgarle a la cuenta de servicio los permisos mínimos necesarios para que logre su objetivo. A fin de obtener más información, consulta Otorga funciones a una cuenta de servicio para recursos específicos.

Cuando les otorgas permisos a los usuarios a fin de que accedan a una cuenta de servicio, ten en cuenta que esos usuarios pueden acceder a todos los recursos a los que tiene acceso la cuenta de servicio mediante 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 que cuentan con funciones de Cloud IAM para actualizar las instancias de App Engine y Compute Engine (como la función de implementador de App Engine o administrador de instancias de Compute) pueden ejecutar código como las cuentas de servicio usadas para 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. A fin de obtener más información, consulta Otorga funciones a una cuenta de servicio para recursos específicos.

  • 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.