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
Enable the IAM and Service Account Credentials APIs.
Comprende las cuentas de servicio de IAM
Si aún no lo has hecho, habilita la facturación y la API de IAM mediante los pasos que figuran en la guía de inicio rápido.
Identifica las cuentas de servicio que usarás en tu cadena de delegación.
Puedes crear una cuenta de servicio nueva y, luego, incluirla en la cadena de delegación si es necesario.
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 aSA_3
. Esta cuenta solo pasa la solicitud; no le da acceso adicional aSA_1
ni aSA_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, comomy-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, comomy-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:my-user@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, comomy-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, comomy-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:
- Tokens de acceso de OAuth 2.0
- Tokens de ID de OpenID Connect
- Tokens web JSON (JWT) autofirmados
- Objetos binarios autofirmados (BLOB)
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, comomy-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 campodelegates
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 es300s
.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, comomy-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 campodelegates
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ónexp
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, comomy-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 campodelegates
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.