Crea credenciales de corta duración para una cuenta de servicio

En esta página se explica cómo actuar en nombre de una cuenta de servicio mediante la creación de credenciales de corta duración para esa cuenta de servicio.

Algunas arquitecturas del sistema están diseñadas en torno a las cuentas de servicio con privilegios limitados, que están diseñadas para usarse en conjunto. En este caso, es posible que debas crear tus credenciales desde varias cuentas de servicio.

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

Las cuentas de servicio pueden usar credenciales de corta duración para autenticar llamadas a las API de Google Cloud, a otras API de Google y a API que no sean de Google. Las credenciales de corta duración tienen una vida útil limitada, con una duración de unas pocas horas o menos. 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.

Las credenciales de corta duración se pueden representar como tokens de acceso de OAuth 2.0, tokens de ID de OpenID Connect, tokens web JSON (JWT) autofirmados y objetos binarios autofirmados (BLOB). Los tipos de credenciales que más se usan son los tokens de acceso de OAuth 2.0 y los tokens de ID de OpenID Connect (OIDC). Puedes usar cada tipo de token en las siguientes situaciones:

  • Token de acceso de OAuth 2.0: Este token es útil para autenticar el acceso desde una cuenta de servicio a las API de Google Cloud. Considera el siguiente caso de uso de ejemplo: para obtener permisos elevados en un proyecto, un administrador puede crear un token de acceso de OAuth 2.0 que pertenezca a una cuenta de servicio y, luego, usar ese token para actuar en nombre de la cuenta de servicio cuando llame a las API de Google Cloud. El token tiene una vida útil corta, por lo que los permisos elevados son temporales. Si usas tokens de corta duración, podrás implementar el principio de privilegio mínimo en todas las identidades y los recursos. También puede ser útil cuando hay una emergencia en un entorno de producción y un administrador necesita una autorización elevada de corta duración para realizar depuraciones.
  • Token de ID de OIDC: Este es útil para autenticar la identidad de una cuenta de servicio ante los servicios que acepten OpenID Connect. Considera el siguiente caso de uso de ejemplo: si se crea un token de ID de OIDC que pertenece a una cuenta de servicio, una carga de trabajo que se ejecuta en Google Cloud se puede autenticar en otra carga de trabajo implementada en un proveedor de servicios en la nube externo, como un trabajo de canalización de datos. Si el servicio de destino se configura con OIDC, la autenticación tendrá éxito.

Flujo de solicitud directa

Cuando creas credenciales de corta duración para una cuenta de servicio mediante un flujo de solicitud directa, el emisor realiza una solicitud directa a fin de crear credenciales de corta duración. En este flujo, participan dos identidades: el emisor y la cuenta de servicio para la que se creó la credencial.

Si la arquitectura del sistema está diseñada en torno a niveles de cuentas de servicio con privilegios limitados, consulta Crea credenciales de corta duración desde múltiples cuentas de servicio.

Antes de comenzar

Crea una cuenta de servicio

Para comenzar, crea una cuenta de servicio nueva.

Proporciona los permisos necesarios

Una solicitud directa involucra solo dos identidades: el emisor y 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): La cuenta con privilegios limitados para la que se crea la credencial

A fin de otorgar permisos a SA_1 para crear credenciales de corta duración, otórgale 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 los siguientes pasos, se usa la API de REST para otorgar el rol. Sin embargo, también puedes usar la consola de Google Cloud o la CLI de gcloud.

API

Primero, lee la política de permisos para SA_2:

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:admin@example.com"
      ]
    }
  ]
}

Si no asignaste una función 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 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:admin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SA_1@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_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:

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:

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.
  • LIFETIME: Es la cantidad de tiempo que transcurre hasta que el token de acceso caduca, expresada en segundos. Por ejemplo, 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:

{
  "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

Mediante el método serviceAccounts.generateIdToken de la API de credenciales de la cuenta de servicio, se genera un token de ID de OpenID Connect 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.
  • 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/SA_NAME@PROJECT_ID.iam.gserviceaccount.com: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.
  • 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:

{
  "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.
  • 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:

{
  "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"
}