Crear credenciales de duración reducida para varias cuentas de servicio

En esta página se explica cómo crear credenciales de duración reducida para una cuenta de servicio basándose en una cadena de delegación de cuentas de servicio. Puedes usar este método cuando necesites hacer una serie de llamadas de generación de tokens para obtener un token con los permisos que necesitas para completar tu tarea.

Una vez que hayas obtenido una credencial de corta duración, podrás usarla para suplantar la identidad de la cuenta de servicio.

Si puedes generar un token con los permisos necesarios con una sola llamada de generación de tokens, debes crear credenciales de duración reducida para esa cuenta de servicio directamente.

Información sobre cómo crear credenciales de duración reducida

En función del tipo de token que crees, puedes usar credenciales de corta duración para autenticar llamadas a APIs de Google, APIs de terceros o aplicaciones que requieran tokens de ID. Las credenciales de corta duración tienen un tiempo de validez limitado, que puede ser de solo unas horas o menos, y no se actualizan automáticamente. Las credenciales de cuenta de servicio de duración reducida son útiles en situaciones en las que necesitas conceder acceso limitado a recursos a cuentas de servicio de confianza. Además, suponen menos riesgos que las credenciales de larga duración, como las claves de cuentas de servicio.

Puede crear los siguientes tipos de credenciales de duración reducida para una cuenta de servicio:

  • Tokens de acceso de OAuth 2.0

    La mayoría de las APIs de Google aceptan tokens de acceso para la autenticación. Cuando generas un token de acceso para una cuenta de servicio, el token de acceso no incluye un token de actualización, lo que significa que, cuando caduque, debes repetir el proceso de creación de tokens para generar uno nuevo.

    Para obtener más información, consulta Tokens de acceso.

  • Tokens de ID de OpenID Connect (OIDC)

    Los tokens de ID siguen la especificación de OpenID Connect (OIDC). Un número limitado de servicios y aplicaciones aceptan tokens de ID.

    Para obtener más información, consulta Tokens de ID y Autenticación de aplicaciones alojadas en Cloud Run o Cloud Functions.

  • Tokens web JSON (JWTs) autofirmados

    Puedes usar JWTs autofirmados para autenticarte en algunas APIs de Google sin obtener un token de acceso del servidor de autorización. Las APIs implementadas con API Gateway las requieren.

  • Blobs binarios autofirmados

    Los blobs autofirmados son útiles en situaciones en las que necesitas transmitir de forma segura datos binarios arbitrarios, normalmente con fines de autenticación.

Flujo de solicitudes delegadas

El flujo de solicitudes delegadas te permite encadenar solicitudes directas con una sola solicitud, en lugar de tener que hacer varias solicitudes directas en secuencia. En este flujo, la solicitud de una credencial de cuenta de servicio se delega en una o varias cuentas de servicio de una cadena de delegación antes de generar una credencial para la cuenta de servicio final. La credencial resultante solo representa la cuenta de servicio final, no las cuentas de servicio intermedias de la cadena de delegación.

Cada cuenta de servicio de la cadena de delegación debe tener los permisos necesarios en la siguiente cuenta de servicio de la cadena para poder transferir la solicitud.

Si una cuenta de servicio proporciona todos los permisos que necesitas, debes usar el flujo más sencillo que se describe en Crear credenciales de corta duración a partir de una cuenta de servicio.

Antes de empezar

Proporcionar los permisos necesarios

Una solicitud delegada implica más de dos identidades: la persona que llama, una o varias cuentas de servicio en una cadena de delegación y, por último, la cuenta de servicio para la que se crea una credencial. En este flujo, ten en cuenta las siguientes identidades:

  • Cuenta de servicio 1 (SA_1), la persona que llama y que emite una solicitud de credenciales de corta duración.
  • Cuenta de servicio 2 (SA_2), una cuenta de servicio intermediaria que delegará la solicitud inicial en SA_3. Esta cuenta solo reenvía la solicitud, pero no da acceso adicional a SA_1 ni a SA_3.
  • Cuenta de servicio 3 (SA_3), la cuenta con privilegios limitados para la que se crea la credencial.

Para permitir la delegación, cada cuenta debe asignar el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) a la cuenta anterior de la cadena.

En este ejemplo concreto, a SA_1 se le debe asignar el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en SA_2. Este es un ejemplo de cómo se trata la cuenta de servicio SA_2 como un recurso: cuando le asignas el rol a SA_2, actualizas su política de permisos de la misma forma que lo harías con cualquier otro recurso.

En este ejemplo, solo hay una cuenta de servicio intermediaria. Para delegar el acceso a través de más de una cuenta de servicio, también debes asignar este rol a cualquier otra cuenta de servicio de la cadena.

A continuación, también se debe asignar a SA_2 el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en SA_3. Esto permite que SA_2 cree credenciales de corta duración para SA_3.

En los siguientes pasos se usa la API REST para asignar los roles. Sin embargo, también puedes usar la Trusted Cloud consola o la CLI de gcloud.

API

Primero, obtén la política de permiso de SA_2 (la cuenta de servicio intermediaria):

El método serviceAccounts.getIamPolicy obtiene la política de autorización de una cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
  • SA_2: nombre de la cuenta de servicio 2.
  • POLICY_VERSION: la versión de la política que se va a devolver. En las solicitudes se debe especificar la versión de la política más reciente, que es la versión 3. Consulta Especificar una versión de la política al obtener una política para obtener más información.

Método HTTP y URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:getIamPolicy

Cuerpo JSON de la solicitud: 

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

Deberías recibir una respuesta JSON similar a la siguiente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    }
  ]
}

Si no has asignado ningún rol a la cuenta de servicio, la respuesta solo contendrá un valor etag. Incluye ese valor de etag en el siguiente paso.

A continuación, modifica la política de permisos para asignar a SA_1 el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator).

Por ejemplo, para modificar la respuesta de ejemplo del paso anterior, añade lo siguiente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.s3ns-system.iam.gserviceaccount.com"
      ]
    }
  ]
}

A continuación, escribe la política de permiso actualizada para SA_2:

El método serviceAccounts.setIamPolicy define una política de permiso actualizada para la cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
  • SA_2: nombre de la cuenta de servicio 2.

  • POLICY: representación JSON de la política que quieres definir. Para obtener más información sobre el formato de una política, consulta la referencia de la política.

    Por ejemplo, para definir la política de permiso que se muestra en el paso anterior, sustituya POLICY por lo siguiente:

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.s3ns-system.iam.gserviceaccount.com"
      ]
    }
  ]
}

Método HTTP y URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_2@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:setIamPolicy

Cuerpo JSON de la solicitud: 

{
  "policy": POLICY
}

Para enviar tu solicitud, despliega una de estas opciones:

La respuesta contiene la política de permiso actualizada.

Ahora, obtén la política de autorización de SA_3 (la cuenta de servicio para la que se crea la credencial):

El método serviceAccounts.getIamPolicy obtiene la política de autorización de una cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
  • SA_3: nombre de la cuenta de servicio 3.
  • POLICY_VERSION: la versión de la política que se va a devolver. En las solicitudes se debe especificar la versión de la política más reciente, que es la versión 3. Consulta Especificar una versión de la política al obtener una política para obtener más información.

Método HTTP y URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:getIamPolicy

Cuerpo JSON de la solicitud: 

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

Deberías recibir una respuesta JSON similar a la siguiente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    }
  ]
}

Si no has asignado ningún rol a la cuenta de servicio, la respuesta solo contiene un valor etag. Incluye ese valor de etag en el siguiente paso.

A continuación, modifica la política de permisos para asignar a SA_2 el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator).

Por ejemplo, para modificar la respuesta de ejemplo del paso anterior, añade lo siguiente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.s3ns-system.iam.gserviceaccount.com"
      ]
    }
  ]
}

Por último, escribe la política de permiso actualizada:

El método serviceAccounts.setIamPolicy define una política de permiso actualizada para la cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
  • SA_3: nombre de la cuenta de servicio 3.

  • POLICY: representación JSON de la política que quieres definir. Para obtener más información sobre el formato de una política, consulta la referencia de la política.

    Por ejemplo, para definir la política de permiso que se muestra en el paso anterior, sustituya POLICY por lo siguiente:

    {
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.s3ns-system.iam.gserviceaccount.com"
      ]
    }
  ]
}

Método HTTP y URL: 

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_3@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:setIamPolicy

Cuerpo JSON de la solicitud: 

{
  "policy": POLICY
}

Para enviar tu solicitud, despliega una de estas opciones:

La respuesta contiene la política de permiso actualizada.

Solicitar credenciales de duración reducida

Una vez que hayas concedido los roles adecuados a cada identidad, podrás solicitar credenciales de corta duración para la cuenta de servicio que quieras. Se admiten los siguientes tipos de credenciales:

Para saber cómo especificar una cadena de delegación para estas solicitudes, consulta la sección Especificar una cadena de delegación de esta página.

Generar un token de acceso OAuth 2.0

De forma predeterminada, los tokens de acceso de OAuth 2.0 son válidos durante 1 hora (3600 segundos) como máximo. Sin embargo, puedes ampliar el tiempo de vida máximo de estos tokens a 12 horas (43.200 segundos). Para ello, identifica las cuentas de servicio cuyos tokens necesitan un tiempo de vida mayor y, a continuación, añádelas a una política de organización que incluya la restricción de la lista constraints/iam.allowServiceAccountCredentialLifetimeExtension. Después, cuando crees un token para estas cuentas de servicio, podrás especificar un ciclo de vida de hasta 43.200 segundos.

Para generar un token de acceso OAuth 2.0 para una cuenta de servicio, sigue estos pasos:

API

La API Service Account Credentials serviceAccounts.generateAccessToken genera un token de acceso de OAuth 2.0 para una cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • SA_NAME: el nombre de la cuenta de servicio para la que quieres crear un token.
  • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
  • DELEGATES: Si usas un flujo de solicitudes delegadas, consulta la sección Especificar una cadena de delegación de esta página. Si utiliza un flujo de solicitud directa sin delegación, omita el campo delegates en el cuerpo de la solicitud.

  • LIFETIME: cantidad de tiempo que falta para que caduque el token de acceso, en segundos. Por ejemplo, 300s.

    De forma predeterminada, el tiempo de vida máximo del token es de 1 hora (3600 segundos). Para ampliar el tiempo de vida máximo de estos tokens a 12 horas (43.200 segundos), añade la cuenta de servicio a una política de organización que incluya la restricción de la lista constraints/iam.allowServiceAccountCredentialLifetimeExtension.

Método HTTP y URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:generateAccessToken

Cuerpo JSON de la solicitud: 

{
  "delegates": [
    DELEGATES
  ],
  "scope": [
    "https://www.googleapis.com/auth/cloud-platform"
  ],
  "lifetime": "LIFETIME"
}

Para enviar tu solicitud, despliega una de estas opciones:

Si la solicitud generateAccessToken se ha completado correctamente, el cuerpo de la respuesta contiene un token de acceso de OAuth 2.0 y un tiempo de vencimiento. A continuación, se puede usar el accessToken para autenticar una solicitud en nombre de la cuenta de servicio hasta que se alcance el expireTime: 

{
  "accessToken": "eyJ0eXAi...NiJ9",
  "expireTime": "2020-04-07T15:01:23.045123456Z"
}

Generar tokens de ID de OpenID Connect

Los tokens de ID de OpenID Connect son válidos durante 1 hora (3600 segundos). Para generar un token de ID de una cuenta de servicio, sigue estos pasos:

API

El método serviceAccounts.generateIdToken de la API Service Account Credentials genera un token de ID de OIDC para una cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PRIV_SA: la dirección de correo de la cuenta de servicio con privilegios para la que se crea el token de corta duración.
  • AUDIENCE_NAME: la audiencia del token, normalmente la URL de la aplicación o el servicio al que se usará el token para acceder.

Método HTTP y URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/PRIV_SA:generateIdToken

Cuerpo JSON de la solicitud: 

{
  "audience": "AUDIENCE_NAME",
  "includeEmail": "true"
}

Para enviar tu solicitud, despliega una de estas opciones:

Si la solicitud generateId se ha completado correctamente, el cuerpo de la respuesta contiene un token de ID válido durante 1 hora. La token se puede usar para autenticar una solicitud en nombre de la cuenta de servicio: 

{
  "token": "eyJ0eXAi...NiJ9"
}

Crear un JSON Web Token (JWT) autofirmado

Los JSON Web Tokens (JWTs) autofirmados son útiles en diversas situaciones, como las siguientes:

  • Autenticar una llamada a una API de Google tal como se describe en la guía de autenticación de Google.
  • Comunicarse de forma segura entre servicios de Google o de terceros, como aplicaciones de App Engine. Trusted Cloud En este caso, una aplicación puede firmar un token que otra aplicación puede verificar con fines de autenticación.
  • Tratar una cuenta de servicio como un proveedor de identidades firmando un JWT que contenga reclamaciones arbitrarias sobre un usuario, una cuenta o un dispositivo.

Para generar un JWT autofirmado para una cuenta de servicio, sigue estos pasos:

API

El método serviceAccounts.signJwt de la API Service Account Credentials firma un JWT con la clave privada gestionada por el sistema de una cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • SA_NAME: el nombre de la cuenta de servicio para la que quieres crear un token.
  • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
  • DELEGATES: Si usas un flujo de solicitudes delegadas, consulta la sección Especificar una cadena de delegación de esta página. Si utiliza un flujo de solicitud directa sin delegación, omita el campo delegates en el cuerpo de la solicitud.

  • JWT_PAYLOAD: la carga útil de JWT que se va a firmar, que es un objeto JSON que contiene un conjunto de reclamaciones de JWT. Incluye las reclamaciones necesarias para el caso práctico que quieras y para cumplir los requisitos de validación del servicio al que llamas. Si llamas a una API de Google, consulta la guía de autenticación de Google para ver los requisitos de las reclamaciones.

    La reclamación exp (hora de vencimiento) no debe ser posterior a 12 horas. Si llamas a una API de Google, la reclamación exp no debe establecerse con más de una hora de antelación.

    La siguiente carga útil de ejemplo contiene reclamaciones para llamar a una API de Google, donde EXP es una marca de tiempo entera que representa la hora de vencimiento: 

    { \"iss\": \"SA_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com\", \"sub\": \"SA_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com\", \"aud\": \"https://firestore.googleapis.com/\", \"iat\": 1529350000, \"exp\": EXP }

Método HTTP y URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:signJwt

Cuerpo JSON de la solicitud: 

{
  "delegates": [
    DELEGATES
  ],
  "payload": "JWT_PAYLOAD"
}

Para enviar tu solicitud, despliega una de estas opciones:

Si la solicitud signJwt se ha completado correctamente, el cuerpo de la respuesta contiene un JWT firmado y el ID de la clave de firma que se ha usado para firmar el JWT. Puedes usar el valor signedJwt como token de portador para autenticar directamente una solicitud en nombre de la cuenta de servicio. El token es válido hasta la hora de vencimiento especificada en la solicitud: 

{
  "keyId": "42ba1e...fc0a",
  "signedJwt": "eyJ0eXAi...NiJ9"
}

Crear un blob autofirmado

Los blobs autofirmados son útiles en situaciones en las que necesitas transmitir de forma segura datos binarios arbitrarios, normalmente con fines de autenticación. Por ejemplo, si quieres usar un protocolo o un tipo de token personalizado (que no sea JWT), puedes incluir esos datos en un blob firmado para que los use un servicio posterior.

Para generar un blob autofirmado para una cuenta de servicio, sigue estos pasos:

API

El método serviceAccounts.signBlob de la API Service Account Credentials firma un blob mediante la clave privada gestionada por el sistema de una cuenta de servicio.

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • SA_NAME: el nombre de la cuenta de servicio para la que quieres crear un token.
  • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
  • DELEGATES: Si usas un flujo de solicitudes delegadas, consulta la sección Especificar una cadena de delegación de esta página. Si utiliza un flujo de solicitud directa sin delegación, omita el campo delegates en el cuerpo de la solicitud.
  • BLOB_PAYLOAD: cadena de bytes codificada en base64. Por ejemplo, VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu.

Método HTTP y URL: 

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:signBlob

Cuerpo JSON de la solicitud: 

{
  "delegates": [
    DELEGATES
  ],
  "payload": "BLOB_PAYLOAD"
}

Para enviar tu solicitud, despliega una de estas opciones:

Si la solicitud signBlob se ha completado correctamente, el cuerpo de la respuesta contiene un blob firmado y el ID de la clave de firma que se ha usado para firmar el blob. Puedes usar el valor signedBlob como token de portador para autenticar directamente una solicitud en nombre de la cuenta de servicio. El token es válido hasta que caduque la clave privada gestionada por el sistema de la cuenta de servicio. El ID de esta clave es el valor del campo keyId de la respuesta. 

{
  "keyId": "42ba1e...fc0a",
  "signedBlob": "eyJ0eXAi...NiJ9"
}

Especificar una cadena de delegación

Cuando se usa un flujo de solicitudes delegadas para crear credenciales de cuenta de servicio de corta duración, el cuerpo de la solicitud de cada API debe especificar la cadena de delegación de la cuenta de servicio en el orden correcto y con el siguiente formato:

projects/-/serviceAccounts/SA_ID

Sustituye SA_ID por el ID numérico único de la cuenta de servicio o por la dirección de correo de la cuenta de servicio.

Por ejemplo, en una cadena de delegación que va de SA_1 (llamador) a SA_2 (delegado), a SA_3 (delegado) y a SA_4, el campo delegates[] contendría SA_2 y SA_3 en el siguiente orden:

{
  "delegates": [
    "projects/-/serviceAccounts/SA_2@PROJECT_ID.s3ns-system.iam.gserviceaccount.com",
    "projects/-/serviceAccounts/SA_3@PROJECT_ID.s3ns-system.iam.gserviceaccount.com"
  ]
}

La persona que llama y la cuenta de servicio para la que se crean las credenciales no se incluyen en la cadena de delegación.