En esta página, se explica cómo crear credenciales de corta duración para que las cuentas de servicio simulen sus identidades.
Las cuentas de servicio pueden usar credenciales de corta duración para autenticar llamadas a las API de Google Cloud y a otras 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 cuenta de servicio de corta duración 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.
Los tipos de credenciales admitidos incluyen 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). A continuación, se muestran algunas situaciones de ejemplo:
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 práctico de ejemplo: a fin de obtener permisos elevados en un proyecto, un administrador de servicios puede simular la identidad de una cuenta de servicio para llamar a API de Google Cloud mediante la creación de un token de acceso de OAuth 2.0 que pertenezca a esa cuenta de servicio. 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 de servicios 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 de los servicios que acepten OpenID Connect. Considera el siguiente caso práctico de ejemplo: si se crea un token de ID de OIDC que pertenece a una cuenta de servicio, un servicio que se ejecuta en Google Cloud se puede autenticar en otro servicio implementado en un proveedor de servicios en la nube de terceros, como un trabajo de canalización de datos. Si el servicio de destino se configura con OIDC, la autenticación tendrá éxito.
Antes de comenzar
Enable the IAM and Service Account Credentials APIs.
Comprende las cuentas de servicio de IAM
Si aún no lo hiciste, habilita la facturación y la API de IAM mediante los pasos que figuran en la Guía de inicio rápido.
Crea una cuenta de servicio
Para comenzar, crea una cuenta de servicio nueva.
Proporciona los permisos necesarios
Hay dos flujos diferentes que permiten al emisor crear credenciales de corta duración para una cuenta de servicio. Cada flujo requiere los permisos adecuados:
- Solicitud directa: El emisor se autentica como una Cuenta de Google o una cuenta de servicio y realiza una solicitud directa para 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.
Solicitud delegada: Al igual que en el flujo de solicitud directa, el emisor se autentica como una Cuenta de Google o una cuenta de servicio, pero la solicitud se delega a una o más cuentas de servicio en una cadena de delegación. En este flujo, varias cuentas de servicio actúan como intermediarias entre el emisor original y la cuenta de servicio para la que se creó la credencial. Cada cuenta de servicio en la cadena de delegación debe tener los permisos necesarios para pasar la solicitud.
Este flujo es útil para situaciones en las que un proyecto contiene niveles de cuentas de servicio con privilegios limitados, cada una configurada para realizar una función específica o limitada en ciertos recursos. Por ejemplo, una cuenta de servicio solo tiene permisos para los recursos de Cloud Storage, otra solo tiene permisos para los recursos de Compute Engine, etcétera. Para delegar con éxito una solicitud entre cuentas de servicio, cada una debe estar incluida en la cadena de delegación.
Permisos de solicitud directa
Como se describe en Otorga permisos necesarios en esta página, 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 la función. Sin embargo, también puedes usar la consola de 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, 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: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, 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: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:
Permisos de solicitud delegada
Como se describe en Otorga permisos necesarios en esta página, 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. 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
- 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 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:admin@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:admin@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: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, 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:admin@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:admin@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:admin@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)
A fin de 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. 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:
{ "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
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, comomy-project
.-
AUDIENCE_NAME
: El público del token, generalmente 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/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, 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 a fin de 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.