Crea credenciales de corta duración para múltiples cuentas de servicio

En esta página, se explica cómo crear credenciales de corta duración para una cuenta de servicio según una cadena de delegación de cuentas de servicio. Puedes usar este enfoque cuando necesites emitir una serie de llamadas de generación de tokens para obtener un token con los permisos que necesitas para realizar la tarea.

Después de obtener una credencial de corta duración, puedes usarla para actuar en nombre de la cuenta de servicio.

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

Acerca de la creación de credenciales de corta duración

Según el tipo de token que crees, puedes usar credenciales de corta duración para autenticar llamadas a las APIs de Google, a APIs de terceros o a aplicaciones que requieran tokens de ID. Las credenciales de corta duración tienen una vida útil limitada, con una duración de unas pocas horas o menos y no se actualizan de forma automática. Las credenciales de corta duración de cuenta de servicio son útiles en situaciones en las que necesitas otorgar acceso limitado a recursos para cuentas de servicio de confianza. También crean menos riesgo que las credenciales de larga duración, como las claves de cuenta de servicio.

Puedes crear los siguientes tipos de credenciales de corta duración 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 viene sin un token de actualización, lo que significa que cuando el token vence, 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). Una cantidad limitada de servicios y aplicaciones aceptan los tokens de ID.

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

  • Tokens web JSON (JWT) autofirmados

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

  • BLOB binarios autofirmados

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

Flujo de solicitud delegada

El flujo de solicitud delegada te permite encadenar solicitudes directas mediante una sola solicitud, en lugar de tener que realizar varias solicitudes directas en secuencia. En este flujo, la solicitud de una credencial de cuenta de servicio se delega a una o más cuentas de servicio en 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 y no las cuentas de servicio intermediaria en la cadena de delegación.

Cada cuenta de servicio en la cadena de delegación debe tener los permisos requeridos en la siguiente cuenta de servicio de la cadena para que pueda pasar la solicitud.

Si una cuenta de servicio proporciona todos los permisos que necesitas, debes usar el flujo más simple descrito en Crea credenciales de corta duración desde una cuenta de servicio.

Antes de comenzar

Otorga los permisos necesarios

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

  • Cuenta de servicio 1 (SA_1): El emisor de una solicitud para las credenciales de corta duración.
  • Cuenta de servicio 2 (SA_2): Una cuenta de servicio intermediaria que delegará la solicitud inicial a SA_3. Esta cuenta solo pasa la solicitud; no le 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 otorgar la función de creador de tokens de cuentas de servicio (roles/iam.serviceAccountTokenCreator) a la cuenta anterior en la cadena.

En este ejemplo en particular, SA_1 debe tener la función de creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en SA_2. Este es un ejemplo de la cuenta de servicio SA_2 que se trata como un recurso: cuando otorgas el rol en SA_2, debes actualizar su política de permisos de la misma manera en que lo harías con cualquier otro recurso.

En este flujo de ejemplo, hay una sola cuenta de servicio intermediaria. Para delegar el acceso a través de más de una cuenta de servicio, también debes asignar esta función a cualquier otra cuenta de servicio en la cadena.

A continuación, SA_2 también debe tener la función de 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 de REST para otorgar los roles. Sin embargo, también puedes usar la consola de Google Cloud o la CLI de gcloud.

API

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

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

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • PROJECT_ID: El ID del proyecto de Google Cloud Los ID de proyecto son strings alfanuméricas, como my-project.
  • SA_2: Es el nombre de la cuenta de servicio 2.
  • POLICY_VERSION: Es la versión de la política que se mostrará. Las solicitudes deben especificar la versión de política más reciente, que es la versión de política 3. Consulta Especifica una versión de política cuando obtienes una política para obtener más detalles.

Método HTTP y URL:

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

Cuerpo JSON de la solicitud:

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

Para enviar tu solicitud, expande una de estas opciones:

Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    }
  ]
}

Si no otorgaste una función a la cuenta de servicio, la respuesta contendrá solo un valor etag. Incluye ese valor de etag en el siguiente paso.

A continuación, modifica la política para otorgar a SA_1 el rol Service Account Token Creator (roles/iam.serviceAccountTokenCreator).

Por ejemplo, para modificar la respuesta de muestra del paso anterior, agrega lo siguiente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

Luego, escribe la política de permisos actualizada para SA_2:

Mediante el método serviceAccounts.setIamPolicy, se configura una política de permisos actualizada para la cuenta de servicio.

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • PROJECT_ID: El ID del proyecto de Google Cloud Los ID de proyecto son strings alfanuméricas, como my-project.
  • SA_2: Es el nombre de la cuenta de servicio 2.
  • POLICY: Una representación JSON de la política que deseas establecer. Para obtener más información sobre el formato de una política, consulta Referencia de políticas.

    Por ejemplo, para establecer la política de permisos que se muestra en el paso anterior, reemplaza POLICY por lo siguiente:

    {
      "version": 1,
      "etag": "BwWKmjvelug=",
      "bindings": [
        {
          "role": "roles/serviceAccountAdmin",
          "members": [
            "user:admin@example.com"
          ]
        },
        {
          "role": "roles/iam.serviceAccountTokenCreator",
          "members": [
            "serviceAccount:SA_1@PROJECT_ID.iam.gserviceaccount.com"
          ]
        }
      ]
    }

Método HTTP y URL:

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

Cuerpo JSON de la solicitud:

{
  "policy": POLICY
}

Para enviar tu solicitud, expande una de estas opciones:

La respuesta contiene la política de permisos actualizada:

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

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

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • PROJECT_ID: El ID del proyecto de Google Cloud Los ID de proyecto son strings alfanuméricas, como my-project.
  • SA_3: Es el nombre de la cuenta de servicio 3.
  • POLICY_VERSION: Es la versión de la política que se mostrará. Las solicitudes deben especificar la versión de política más reciente, que es la versión de política 3. Consulta Especifica una versión de política cuando obtienes una política para obtener más detalles.

Método HTTP y URL:

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

Cuerpo JSON de la solicitud:

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

Para enviar tu solicitud, expande una de estas opciones:

Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    }
  ]
}

Si no asignaste una función a la cuenta de servicio, la respuesta contendrá solo un valor etag. Incluye ese valor de etag en el siguiente paso.

A continuación, modifica la política para otorgar a SA_2 el rol Service Account Token Creator (roles/iam.serviceAccountTokenCreator).

Por ejemplo, para modificar la respuesta de muestra del paso anterior, agrega lo siguiente:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:my-user@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

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

Mediante el método serviceAccounts.setIamPolicy, se configura una política de permisos actualizada para la cuenta de servicio.

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • PROJECT_ID: El ID del proyecto de Google Cloud Los ID de proyecto son strings alfanuméricas, como my-project.
  • SA_3: Es el nombre de la cuenta de servicio 3.
  • POLICY: Una representación JSON de la política que deseas establecer. Para obtener más información sobre el formato de una política, consulta Referencia de políticas.

    Por ejemplo, para establecer la política de permisos que se muestra en el paso anterior, reemplaza POLICY por lo siguiente:

    {
      "version": 1,
      "etag": "BwWKmjvelug=",
      "bindings": [
        {
          "role": "roles/serviceAccountAdmin",
          "members": [
            "user:my-user@example.com"
          ]
        },
        {
          "role": "roles/iam.serviceAccountTokenCreator",
          "members": [
            "serviceAccount:SA_2@PROJECT_ID.iam.gserviceaccount.com"
          ]
        }
      ]
    }

Método HTTP y URL:

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

Cuerpo JSON de la solicitud:

{
  "policy": POLICY
}

Para enviar tu solicitud, expande una de estas opciones:

La respuesta contiene la política de permisos actualizada:

Solicita credenciales de corta duración

Después de otorgar las funciones adecuadas a cada identidad, puedes solicitar credenciales de corta duración para la cuenta de servicio deseada. Se admiten los siguientes tipos de credenciales:

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

Genera un token de acceso de OAuth 2.0

De forma predeterminada, los tokens de acceso de OAuth 2.0 son válidos durante un máximo de 1 hora (3,600 segundos). Sin embargo, puedes extender la vida útil máxima de estos tokens a 12 horas (43,200 segundos). Si deseas hacerlo, identifica las cuentas de servicio que necesitan una vida útil prolongada para los tokens, agrega estas cuentas de servicio a una política de la organización que incluye la restricción de listas constraints/iam.allowServiceAccountCredentialLifetimeExtension. Luego, puedes especificar una vida útil de hasta 43,200 segundos cuando creas un token para estas cuentas de servicio.

A fin de generar un token de acceso de OAuth 2.0 para una cuenta de servicio, haz lo siguiente:

API

Mediante el método serviceAccounts.generateAccessToken de la API de credenciales de la cuenta de servicio, se genera un token de acceso de OAuth 2.0 para una cuenta de servicio.

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • SA_NAME: Es el nombre de la cuenta de servicio para la que deseas crear un token.
  • PROJECT_ID: El ID del proyecto de Google Cloud Los ID de proyecto son strings alfanuméricas, como my-project.
  • DELEGATES: Si usas un flujo de solicitud delegada, consulta Especifica una cadena de delegación en esta página. Si usas un flujo de solicitud directa sin delegación, omite el campo delegates en el cuerpo de la solicitud.
  • LIFETIME: Es la cantidad de tiempo que transcurre hasta que el token de acceso caduca, expresada en segundos. Un ejemplo es 300s.

    De forma predeterminada, la vida útil máxima del token es de 1 hora (3,600 segundos). Para extender la vida útil máxima de estos tokens a 12 horas (43,200 segundos), agrega la cuenta de servicio a una política de la organización que incluya la restricción de lista constraints/iam.allowServiceAccountCredentialLifetimeExtension.

Método HTTP y URL:

POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.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, expande una de estas opciones:

Si la solicitud generateAccessToken tiene éxito, el cuerpo de la respuesta contendrá un token de acceso de OAuth 2.0 y un tiempo de caducidad. El accessToken se puede usar para autenticar una solicitud en nombre de la cuenta de servicio hasta que se haya alcanzado el expireTime.

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

Genera tokens de ID de OpenID Connect

Los tokens de ID de OpenID Connect son válidos por 1 hora (3,600 segundos). Para generar un token de ID en nombre de una cuenta de servicio, haz lo siguiente:

API

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

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • PRIV_SA: Es la dirección de correo electrónico de la cuenta de servicio con privilegios para la que se crea el token de corta duración.
  • AUDIENCE_NAME: El público del token, generalmente la URL de la aplicación o el servicio a los que se quiere acceder con el token

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, expande una de estas opciones:

Si la solicitud generateId tuvo éxito, el cuerpo de la respuesta contendrá un token de ID válido por 1 hora. Se puede usar el token para autenticar una solicitud en nombre de la cuenta de servicio.

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

Crea un token web JSON (JWT) autofirmado

Los tokens web JSON (JWT) autofirmados son útiles en varias situaciones, como las que se muestran a continuación:

  • Autenticación de una llamada a una API de Google como se describe en la Guía de autenticación de Google
  • Comunicación segura entre servicios de Google Cloud o servicios que no sean de Google, como las aplicaciones de App Engine. En esta situación, 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 identidad mediante la firma de un JWT que contiene reclamaciones arbitrarias sobre un usuario, una cuenta o un dispositivo

A fin de generar un JWT autofirmado para una cuenta de servicio, haz lo siguiente:

API

Con el método serviceAccounts.signJwt de la API de credenciales de la cuenta de servicio, se firma un JWT mediante la clave privada administrada por el sistema de una cuenta de servicio.

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • SA_NAME: Es el nombre de la cuenta de servicio para la que deseas crear un token.
  • PROJECT_ID: El ID del proyecto de Google Cloud Los ID de proyecto son strings alfanuméricas, como my-project.
  • DELEGATES: Si usas un flujo de solicitud delegada, consulta Especifica una cadena de delegación en esta página. Si usas un flujo de solicitud directa sin delegación, omite el campo delegates en el cuerpo de la solicitud.
  • JWT_PAYLOAD: Es la carga útil del JWT que se firmará, que es un objeto JSON que contiene un conjunto de reclamaciones de JWT. Incluye las reclamaciones necesarias para tu caso de uso deseado a fin de cumplir con 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 conocer los requisitos de reclamación.

    La reclamación exp (tiempo de caducidad) no debe ser superior a 12 horas. Si llamas a una API de Google, la reclamación exp no se debe establecer en más de 1 hora.

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

    { \"iss\": \"SA_NAME@PROJECT_ID.iam.gserviceaccount.com\", \"sub\": \"SA_NAME@PROJECT_ID.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.iam.gserviceaccount.com:signJwt

Cuerpo JSON de la solicitud:

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

Para enviar tu solicitud, expande una de estas opciones:

Si la solicitud signJwt se realizó con éxito, el cuerpo de la respuesta contendrá un JWT firmado y el ID de la clave de firma que se usó para firmarlo. Puedes usar el valor signedJwt como un token del portador para autenticar directamente una solicitud en nombre de la cuenta de servicio. El token es válido hasta que venza el tiempo de caducidad especificado en la solicitud:

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

Crea un BLOB autofirmado

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

Para generar un BLOB autofirmado en nombre de una cuenta de servicio, haz lo siguiente:

API

Con el método serviceAccounts.signBlob de la API de credenciales de la cuenta de servicio, se firma un blob mediante la clave privada administrada por el sistema de una cuenta de servicio.

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

  • SA_NAME: Es el nombre de la cuenta de servicio para la que deseas crear un token.
  • PROJECT_ID: El ID del proyecto de Google Cloud Los ID de proyecto son strings alfanuméricas, como my-project.
  • DELEGATES: Si usas un flujo de solicitud delegada, consulta Especifica una cadena de delegación en esta página. Si usas un flujo de solicitud directa sin delegación, omite el campo delegates en el cuerpo de la solicitud.
  • BLOB_PAYLOAD: Es una string 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.iam.gserviceaccount.com:signBlob

Cuerpo JSON de la solicitud:

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

Para enviar tu solicitud, expande una de estas opciones:

Si la solicitud signBlob se realizó con éxito, el cuerpo de la respuesta contendrá un BLOB firmado y el ID de la clave de firma que se usó para firmarlo. Puedes usar el valor signedBlob como un token del portador para autenticar directamente una solicitud en nombre de la cuenta de servicio. El token es válido hasta que caduque la clave privada administrada por el sistema de la cuenta de servicio. El ID de esta clave es el valor del campo keyId en la respuesta.

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

Especifica una cadena de delegación

Cuando usas un flujo de solicitud delegada para crear credenciales de cuenta de servicio de corta duración, el cuerpo de la solicitud para cada API debe especificar la cadena de delegación de cuentas de servicio en el orden correcto y en el siguiente formato:

projects/-/serviceAccounts/SA_ID

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

Por ejemplo, en una cadena de delegación que fluye desde SA_1 (emisor) y pasa por SA_2 (delegada) y SA_3 (delegada) hasta llegar a SA_4, el campo delegates[] contendrá a SA_2 y SA_3 en el siguiente orden:

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

El emisor y la cuenta de servicio para la que se creó la credencial no se incluyen en la cadena de delegación.