Al igual que cualquier principal, una cuenta de servicio puede autenticarse en Google, obtener un token de acceso de OAuth 2.0 y llamar a las APIs de Google. Sin embargo, este proceso funciona de manera diferente para las cuentas de servicio y para los usuarios.
Las cuentas de servicio se autentican mediante una de las siguientes opciones:
- Obtener credenciales de corta duración
- Usar una clave de cuenta de servicio para firmar un token web JSON (JWT) y, luego, intercambiarlo por un token de acceso
Credenciales de cuentas de servicio de corta duración
La forma más segura de autenticarse como una cuenta de servicio es obtener credenciales de corta duración para la cuenta de servicio en forma de un token de acceso de OAuth 2.0. De forma predeterminada, estos tokens vencen después de 1 hora.
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.
En muchos casos, estas credenciales se obtienen de forma automática, no es necesario que las crees o las administres. Estos son algunos ejemplos:
- Si se ejecuta un comando de Google Cloud CLI y se incluye la marca
--impersonate-service-account, la CLI de gcloud crea credenciales de corta duración para la cuenta de servicio y se ejecuta el comando con esas credenciales. Si se adjunta una cuenta de servicio a una instancia de máquina virtual (VM) de Compute Engine, las cargas de trabajo en esa instancia pueden usar las bibliotecas cliente de Cloud para acceder a los servicios de Google Cloud. Las bibliotecas cliente de Cloud usan las credenciales predeterminadas de la aplicación (ADC) a fin de obtener credenciales de corta duración para la cuenta de servicio.
Para obtener detalles sobre este proceso, consulta Autentica aplicaciones mediante credenciales de cuenta de servicio.
Si configuraste la federación de identidades para cargas de trabajo, las bibliotecas cliente de Cloud pueden usar credenciales de tu proveedor de identidad para generar credenciales de cuenta de servicio de corta duración.
También puedes usar la API de Service Account Credentials para crear credenciales de corta duración de forma manual. Por ejemplo, puedes crear un servicio que otorgue a los usuarios credenciales de cuenta de servicio de corta duración para permitirles acceder a los recursos de Google Cloud de forma temporal.
La API de Service Account Credentials puede crear los siguientes tipos de credenciales:
- Tokens de acceso de OAuth 2.0
- Tokens de ID de OpenID Connect (OIDC)
- Tokens web JSON (JWT) autofirmados
- BLOB binarios autofirmados
A fin de obtener más información, consulta Crea credenciales de cuenta de servicio de corta duración.
Interpreta los registros de auditoría
Los Registros de auditoría de Cloud te ayudan a responder las preguntas “¿Quién hizo qué, dónde y cuándo?” para tus recursos de Google Cloud.
Cuando usas credenciales de corta duración para actuar en nombre de una cuenta de servicio, la mayoría de los servicios de Google Cloud crean entradas de registro que muestran las siguientes identidades:
- La cuenta de servicio que suplantan las credenciales de corta duración
- La identidad que creó las credenciales de corta duración
Puedes usar estas entradas de registro para identificar a la principal que creó las credenciales de corta duración, así como la cuenta de servicio cuya identidad usó la principal.
Para ver ejemplos de entradas de registro de auditoría que muestran el uso de la identidad de cuentas de servicio, consulta Actúa como una cuenta de servicio para acceder a Google Cloud.
Robo de identidad
Robo de identidad es cuando usas las credenciales de una cuenta de servicio a fin de generar una credencial nueva para la cuenta de servicio.
La API de Service Account Credentials prohíbe los siguientes tipos de robo de identidad:
Usar una credencial de corta duración para una cuenta de servicio a fin de generar un token de acceso nuevo para la cuenta de servicio.
Los tokens web JSON (JWT) autofirmados son la excepción a esta regla. Puedes usar un JWT autofirmado para que una cuenta de servicio genere un token de acceso nuevo para la cuenta de servicio.
Usar una credencial de corta duración para que una cuenta de servicio firme un objeto binario (BLOB) o JWT que se puede usar para llamar a las siguientes APIs:
Google Cloud prohíbe este tipo de robo de identidad porque permite que los actores maliciosos actualicen los tokens robados de forma indefinida.
Si intentas usar el robo de identidad de una de las maneras prohibidas, es posible que encuentres el siguiente error:
FAILED_PRECONDITION: You can't create a token for the same service account that you used to authenticate the request.
Si encuentras este error, intenta usar credenciales diferentes a fin de generar la credencial de corta duración nueva para tu cuenta de servicio, por ejemplo, tus credenciales de usuario final o las credenciales de una cuenta de servicio diferente.
Claves de cuenta de servicio
Cada cuenta de servicio está asociada con un par de clave RSA pública/privada. La API de credenciales de la cuenta de servicio usa este par de claves internas a fin de crear credenciales de cuenta de servicio de corta duración y para firmar BLOB y tokens web JSON (JWT). Este par de claves se conoce como el par de claves administradas por Google.
Además, puedes crear varios pares de claves RSA públicas/privadas, conocidas como pares de claves administradas por el usuario, y usar la clave privada para autenticarte con las API de Google. Esta clave privada se conoce como clave de cuenta de servicio.
Pares de claves administradas por Google
La API de credenciales de la cuenta de servicio usa los pares de claves administradas por Google y los servicios de Google Cloud, como App Engine y Compute Engine, a fin de generar credenciales de corta duración para cuentas de servicio.
Los pares de claves administradas por Google se rotan y usan de forma automática para firmar por un máximo de dos semanas. El proceso de rotación es probabilístico. El uso de la clave nueva aumentará y disminuirá de manera gradual durante el ciclo de vida de la clave.
La clave privada en un par de claves administradas por Google siempre se mantiene guardada y nunca puedes acceder a ella directamente.
La clave pública en un par de claves administradas por Google es de acceso público, de modo que cualquiera pueda verificar las firmas que se crean con la clave privada. Puedes acceder a la clave pública en varios formatos diferentes:
- X.509 certificate:
https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL - Clave web JSON (JWK):
https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL - Formato sin procesar:
https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL
Si descargas la clave pública y la almacenas en caché, te recomendamos almacenarla en caché por un máximo de 24 horas a fin de asegurarte de que siempre tengas la clave actual. Independientemente de cuándo recuperes la clave pública, será válida durante al menos 24 horas después de recuperarla.
Pares de claves administradas por el usuario
Puedes crear pares de claves administradas por el usuario para una cuenta de servicio y, luego, usar la clave privada de cada par de claves para autenticarte con las API de Google. Esta clave privada se conoce como clave de cuenta de servicio.
Las bibliotecas cliente de Cloud pueden usar claves de cuenta de servicio para obtener un token de acceso de OAuth 2.0 de manera automática. También puedes usar una clave de cuenta de servicio para firmar un JWT de forma manual y, luego, usar el JWT firmado a fin de solicitar un token de acceso. Si deseas obtener detalles, consulta Usa OAuth 2.0 para aplicaciones de servidor a servidor.
Cada cuenta de servicio puede tener un máximo de 10 claves de cuentas de servicio. Google almacena solo la parte pública de un par de claves administradas por el usuario.
Existen dos maneras de crear un par de claves administradas por el usuario para una cuenta de servicio:
- Usa la API de IAM para crear un par de claves administradas por el usuario de forma automática. Google genera un par de clave pública/privada, almacena solo la clave pública y te muestra la clave privada.
- Crea un par de claves administradas por el usuario y sube solo la clave pública. Google nunca ve la clave privada.
Las claves administradas por el usuario son credenciales extremadamente potentes. Para limitar el uso de claves administradas por el usuario, puedes aplicar las siguientes restricciones de políticas de la organización a una organización, un proyecto o una carpeta:
constraints/iam.disableServiceAccountKeyCreation: Evita que las principales creen claves de cuenta de servicio administradas por el usuario.constraints/iam.disableServiceAccountKeyUpload: Evita que las principales suban una clave pública para una cuenta de servicio.
Si aplicas estas restricciones porque usas la federación de identidades para cargas de trabajo, considera usar las restricciones de las políticas de la organización para la federación de identidades para cargas de trabajo a fin de especificar qué proveedores de identidad están permitidos.
Plazos de vencimiento de las claves administradas por el usuario
De forma predeterminada, cuando creas una clave de cuenta de servicio administrada por el usuario, esta nunca vence. Puedes cambiar este valor predeterminado si estableces un plazo de vencimiento para todas las claves recién creadas en tu proyecto, organización o carpeta. Un plazo de vencimiento especifica la cantidad de horas durante las cuales una clave recién creada es válida.
Usa plazos de vencimiento cuando necesites acceso temporal a un sistema que requiera una clave de cuenta de servicio. Por ejemplo, usa los plazos de vencimiento cuando hagas lo siguiente:
- Desarrollar código en un entorno que no sea de producción para una aplicación que solo pueda autenticarse con claves de cuenta de servicio
- Usar una herramienta de terceros que solo pueda autenticarse con claves de cuenta de servicio
Evita usar plazos de vencimiento para estas situaciones:
- Cargas de trabajo de producción En producción, una clave de cuenta de servicio vencida podría causar una interrupción accidental. En su lugar, usa claves que no tengan vencimiento y administra su ciclo de vida con la rotación de claves.
- Cargas de trabajo que no son de producción y que necesitan acceso permanente, como una canalización de integración continua (CI)
- Sistemas de rotación de claves que evitan que una clave se use después de un período específico Para obtener información sobre las estrategias de rotación de claves recomendadas, consulta Rotación de claves de cuenta de servicio.
Para evitar interrupciones, te recomendamos que no establezcas un plazo de vencimiento, a menos que la restricción de política de la organización constraints/iam.disableServiceAccountKeyCreation se haya implementado por un período prolongado. Cuando configuras un plazo de vencimiento, también debes dejar de aplicar la restricción constraints/iam.disableServiceAccountKeyCreation. Para obtener detalles sobre esta restricción, consulta Limita la vida útil de las claves de cuenta de servicio.
Para establecer un plazo de vencimiento, haz lo siguiente:
- Identifica el proyecto, la carpeta o la organización en la que deseas establecer un plazo de vencimiento para las claves de la cuenta de servicio.
- Agrega una política de la organización que aplique la restricción
constraints/iam.serviceAccountKeyExpiryHours. Después de actualizar esta limitación para tu proyecto, organización o carpeta, el plazo de vencimiento se aplica a todas las claves de la cuenta de servicio recién creadas dentro de ese recurso superior. Las claves existentes no se ven afectadas.
Los plazos de vencimiento se miden en horas. Como práctica recomendada, usa plazos de vencimiento cortos, como 8 horas; 24 horas (1 día); o 168 horas (7 días) Los plazos de vencimiento cortos ayudan a garantizar que tu equipo tenga un proceso probado para actualizar claves. Comienza con el plazo de vencimiento más corto que satisfaga tus necesidades y auméntalo solo si es necesario.