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 o de forma local?

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

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 a una cuenta de servicio acceso a un recurso es similar a otorgarle acceso a cualquier otra identidad. Por ejemplo, si ejecutas una aplicación en Compute Engine y deseas que solo tenga acceso para crear objetos en 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.

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 miembros 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 la administración de identidades y accesos (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 nueva no estará conectada al recurso.

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, debes revocar las funciones de la cuenta de servicio original y, luego, otorgar las funciones a la cuenta de servicio nueva. Para obtener más información, consulta Políticas con miembros borrados.

Si también necesitas que la cuenta de servicio nueva se conecte a los mismos recursos que la cuenta de servicio original, realiza una de las siguientes acciones:

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. Obtén información sobre cómo otorgar funciones a todos los tipos de miembros, incluidas 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 las 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). Ten mucho cuidado cuando permites que los usuarios actúen en nombre de las cuentas de servicio con demasiados privilegios, como las cuentas de servicio predeterminadas de Compute Engine y App Engine.

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.

Conecta cuentas de servicio a recursos

Si deseas iniciar un trabajo de larga duración que se autentica como una cuenta de servicio, debes conectar una cuenta de servicio al recurso que ejecutará el trabajo.

Permisos:

  • Permisos para crear el recurso
  • iam.serviceAccounts.actAs

Busca las funciones que incluyen estos permisos en la lista de funciones.

Existen varios recursos diferentes de Google Cloud que pueden ejecutar trabajos de larga duración como cuentas de servicio. Algunos ejemplos de estos recursos incluyen los siguientes:

  • VM de Compute Engine
  • Aplicaciones de App Engine
  • Cloud Functions

Cuando creas estos recursos, tienes la opción de conectar una cuenta de servicio. Esta cuenta de servicio actúa como la identidad del recurso.

A fin de crear un recurso y conectar una cuenta de servicio, necesitas permisos para crear ese recurso y actuar en nombre de la cuenta de servicio que conectarás al recurso. Cualquier función que incluya el permiso iam.serviceAccounts.actAs proporciona el permiso para actuar en nombre de la cuenta de servicio.

Después de crear el recurso y conectarle una cuenta de servicio, puedes iniciar un trabajo de larga duración en el recurso. El trabajo se ejecuta como la cuenta de servicio conectada al recurso y usa esa cuenta de servicio para autorizar solicitudes a las API de Google Cloud.

Para obtener más información sobre cómo conectar cuentas de servicio a recursos, consulta Conecta una cuenta de servicio a un recurso.

Actúa 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, por ejemplo, Identity-Aware Proxy, que permite el acceso basado en OIDC a aplicaciones ejecutadas por el usuario.

Genera 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 Google Cloud. Los servicios de Google Cloud, como App Engine y Compute Engine, usan estas claves. No pueden descargarse y se rotan y usan de forma automática para acceder durante dos semanas, como máximo. 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. Recomendamos almacenar en la caché la clave pública que se configuró para la cuenta de servicio por lo menos durante 24 horas a fin de asegurarte de que siempre tengas 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:

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 asegurarte de que tus instancias de Compute Engine sean más 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 volver a crear la instancia.

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