Suplantación de identidad de cuentas de servicio

Cuando un principal autenticado, como un usuario u otra cuenta de servicio, se autentica como una cuenta de servicio para obtener sus permisos, se denomina suplantación de identidad de la cuenta de servicio. Al usar la identidad de una cuenta de servicio, un principal autenticado puede acceder a todo lo que pueda acceder la cuenta de servicio. Solo las entidades autenticadas con los permisos adecuados pueden suplantar cuentas de servicio.

La suplantación de identidad es útil cuando quieres cambiar los permisos de un usuario sin modificar tus políticas de gestión de identidades y accesos (IAM). Por ejemplo, puedes usar la suplantación de identidad para conceder temporalmente a un usuario acceso elevado o para comprobar si un conjunto específico de permisos es suficiente para una tarea. También puedes usar la suplantación para desarrollar aplicaciones de forma local que solo se puedan ejecutar como una cuenta de servicio o para autenticar aplicaciones que se ejecuten fuera de Trusted Cloud.

Trusted Cloud by S3NS La suplantación de identidad de cuentas de servicio es similar a los métodos de la API Security Token Service de Amazon Web Services (AWS), como AssumeRole.

Cómo funciona la suplantación de cuentas de servicio

La suplantación de cuentas de servicio siempre implica dos identidades: una principal autenticada y la cuenta de servicio que suplanta la principal. Para suplantar la cuenta de servicio, la entidad autenticada obtiene un token de la cuenta de servicio y, a continuación, usa ese token para autenticarse como la cuenta de servicio.

Hay varias formas de usar la identidad de una cuenta de servicio:

  • Define la marca --impersonate-service-account o la propiedad impersonate-service-account al ejecutar un comando de la CLI de Google Cloud. Cuando ejecutas un comando de la CLI de gcloud con este ajuste, la CLI de gcloud crea credenciales de corta duración para la cuenta de servicio y, a continuación, ejecuta el comando con esas credenciales.

    También puedes usar la marca --impersonate-service-account al configurar tu archivo de credenciales predeterminadas de la aplicación. Esta configuración permite que las bibliotecas de cliente que admiten la suplantación de identidad suplanten automáticamente la cuenta de servicio.

  • Crea credenciales de duración reducida con la API Service Account Credentials y, a continuación, úsalas para autenticar una solicitud de API.

    Las credenciales de duración reducida tienen una validez limitada, que puede ser de unas horas o menos, y no se actualizan automáticamente. Suponen menos riesgo que las credenciales de larga duración, como las claves de cuentas de servicio.

  • Utiliza un archivo de configuración de credenciales para configurar una aplicación externa que suplante la identidad de una cuenta de servicio. Esta opción solo está disponible para las aplicaciones que usan federación de identidades de cargas de trabajo.

    Cuando una aplicación usa un archivo de configuración de credenciales para acceder aTrusted Cloud, primero usa sus credenciales específicas del entorno para obtener una credencial de corta duración para una cuenta de servicio designada. Después, usa esa credencial de corta duración para autenticarse en Trusted Cloud.

Si un principal accede a recursos mientras suplanta la identidad de una cuenta de servicio, la mayoría de los registros de auditoría incluyen tanto su identidad como la de la cuenta de servicio cuya identidad está suplantando. Para obtener más información, consulta el artículo sobre cómo interpretar registros de auditoría.

Cuando usas la consola de Trusted Cloud , siempre te autenticas con tus credenciales de usuario. No puedes suplantar la identidad de una cuenta de servicio para acceder a los recursos de la consola deTrusted Cloud .

Autenticación sin suplantación de identidad

Hay varias formas de que una carga de trabajo o un usuario se autentiquen como cuenta de servicio sin suplantar la identidad de la cuenta de servicio:

  • Una carga de trabajo usa una cuenta de servicio adjunta para autenticarse en las APIs de Google. En este caso, la cuenta de servicio adjunta actúa como identidad de la carga de trabajo y es la única identidad autenticada que participa en la solicitud.

    Para obtener información sobre cómo se autentican las cargas de trabajo en Trusted Cloud by S3NS, consulta Identidades de cargas de trabajo.

  • Un principal usa una clave de cuenta de servicio para autenticarse como cuenta de servicio. Para autenticarse como cuenta de servicio mediante una clave de cuenta de servicio, solo se necesita una identidad autenticada: la de la cuenta de servicio. Como solo hay una identidad implicada, usar una clave no es una suplantación de identidad de cuenta de servicio.

En estos casos, los registros de auditoría solo registran la identidad de la cuenta de servicio. No registran ninguna otra identidad, como las identidades de los usuarios que ejecutaron código en la carga de trabajo o las identidades de las personas que usaron la clave de la cuenta de servicio para autenticarse. Por lo tanto, usar claves de cuentas de servicio o dar permiso a los desarrolladores para ejecutar código en recursos con privilegios (por ejemplo, una sesión SSH en una instancia de VM) puede generar riesgos de apropiación de privilegios y de no repudio.

Permisos obligatorios

Para suplantar la identidad de una cuenta de servicio, necesitas el permiso iam.serviceAccounts.getAccessToken. Este permiso se incluye en roles como el Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator).

Para obtener más información sobre los roles necesarios para la suplantación de identidad, consulta Roles para la autenticación de cuentas de servicio.

Casos prácticos de la suplantación de cuentas de servicio

La suplantación de identidad de cuentas de servicio es útil cuando necesitas hacer tareas como las siguientes:

  • Conceder acceso elevado temporal a un usuario
  • Probar si un conjunto de permisos específico es suficiente para una tarea
  • Desarrollar aplicaciones de forma local que solo se puedan ejecutar como cuenta de servicio
  • Autenticar aplicaciones externas

Conceder acceso elevado temporal

En algunos casos, puede que quieras permitir que un usuario acceda a recursos específicos de forma temporal. Por ejemplo, puede que quiera dar acceso adicional a alguien para que pueda resolver un incidente o permitir que alguien acceda a datos sensibles durante un tiempo limitado después de haber registrado una justificación.

La suplantación de identidad de una cuenta de servicio es una de las formas de conceder a los usuarios este acceso elevado temporal. Para usar una cuenta de servicio para obtener acceso elevado temporalmente, primero debes concederle los roles de gestión de identidades y accesos que quieras dar a los usuarios de forma temporal. Después, permite que los usuarios suplanten la identidad de la cuenta de servicio. Para ello, puedes darles permiso para que lo hagan o usar un intermediario de tokens para emitir una credencial de corta duración para la cuenta de servicio.

Para obtener más información sobre los métodos para dar a los usuarios acceso elevado temporal, consulta el resumen del acceso elevado temporal.

Probar permisos

En algunos casos, puede que quieras comprobar si un conjunto específico de permisos es suficiente para una tarea. Por ejemplo, puede que quieras confirmar que una cuenta de servicio puede seguir ejecutando una aplicación si eliminas ciertos permisos innecesarios. También puedes ayudar a un usuario a solucionar un problema con una tarea y querer verificar que puede ejecutar un determinado comando con sus roles de gestión de identidades y accesos actuales.

Puedes usar la suplantación de identidad de una cuenta de servicio para probar un conjunto específico de permisos. Primero, crea una cuenta de servicio y concédele uno o varios roles de IAM con los permisos que quieras probar. A continuación, usa la identidad de la cuenta de servicio e intenta realizar la tarea. Este método te permite probar los permisos sin tener que crear cuentas de usuario de prueba ni modificar tus propios permisos de gestión de identidades y accesos.

Para saber cómo suplantar la identidad de cuentas de servicio, consulta Usar la suplantación de identidad de cuentas de servicio.

Desarrollar aplicaciones de forma local

Cuando desarrolles aplicaciones de forma local, normalmente podrás autenticarte con tus credenciales de usuario. Sin embargo, en algunas situaciones, puede que no sea posible. Por ejemplo, si quieres autenticarte en un servicio que requiere un token con una audiencia personalizada, que los usuarios no suelen poder configurar. En estos casos, debes autenticarte como cuenta de servicio en lugar de hacerlo con tus credenciales de usuario.

En estos casos, te recomendamos que uses la suplantación de identidad de la cuenta de servicio. Si usas la suplantación de identidad de cuentas de servicio, no tendrás que usar claves de cuentas de servicio, lo que supone un riesgo de seguridad adicional.

Para saber cómo suplantar la identidad de cuentas de servicio para desarrollar aplicaciones, consulta el artículo sobre la suplantación de identidad de cuentas de servicio.

Autenticar aplicaciones externas

Para acceder a los Trusted Cloud recursos, las aplicaciones que se ejecutan fuera deTrusted Cloud deben autenticarse en Trusted Cloud. Una forma de autenticar estas aplicaciones es usar la suplantación de cuentas de servicio.

Para permitir que tu aplicación suplante la identidad de una cuenta de servicio, primero debes configurar la federación de identidades de cargas de trabajo, que proporciona una identidad autenticada a tu aplicación. Después, puedes usar un archivo de configuración de credenciales para configurar tu aplicación de forma que suplante la identidad de una cuenta de servicio.

Aunque es posible usar claves de cuentas de servicio para autenticar aplicaciones externas, no lo recomendamos. Las claves de cuentas de servicio suponen un riesgo de seguridad adicional y deben evitarse siempre que sea posible.

Siguientes pasos