Credenciales de cuenta de servicio

Al igual que cualquier otro 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 forma diferente en las cuentas de servicio que en las de usuario.

Las cuentas de servicio se autentican de una de las siguientes formas:

Credenciales de cuenta de servicio de duración reducida

La forma más segura de autenticarte como cuenta de servicio es obtener credenciales de corta duración para la cuenta de servicio en forma de token de acceso de OAuth 2.0. De forma predeterminada, estos tokens caducan al cabo de 1 hora.

Las credenciales de cuentas de servicio de duración reducida son útiles en situaciones en las que necesitas conceder acceso limitado a recursos a cuentas de servicio de confianza. Además, con ellas se reducen los riesgos en comparación con las credenciales de larga duración, como las claves de cuentas de servicio.

En muchos casos, estas credenciales se obtienen automáticamente, por lo que no es necesario que las cree ni las gestione usted. A continuación, se incluyen algunos ejemplos:

  • Si ejecutas un comando de la CLI de Google Cloud e incluyes la marca --impersonate-service-account, la CLI de gcloud crea credenciales de corta duración para la cuenta de servicio y ejecuta el comando con esas credenciales.
  • Si asocias una cuenta de servicio a una instancia de máquina virtual (VM) de Compute Engine, las cargas de trabajo de esa instancia podrán usar las bibliotecas de cliente de Cloud para acceder a los servicios de Google Cloud . Las bibliotecas de cliente de Cloud usan las credenciales de aplicación predeterminadas (ADC) para obtener credenciales de corta duración para la cuenta de servicio.

    Para obtener más información sobre este proceso, consulta el artículo Autenticar aplicaciones con credenciales de cuentas de servicio.

  • Si has configurado la federación de identidades de carga de trabajo, las bibliotecas de cliente de Cloud pueden usar las credenciales de tu proveedor de identidades para generar credenciales de cuenta de servicio de corta duración.

También puedes usar la API Service Account Credentials para crear credenciales de corta duración manualmente. Por ejemplo, puedes crear un servicio que proporcione a los usuarios credenciales de cuentas de servicio de corta duración para que puedan acceder temporalmente a los recursos. Google Cloud

La API de credenciales de cuentas de servicio puede crear los siguientes tipos de credenciales:

  • Tokens de acceso de OAuth 2.0
  • Tokens de ID de OpenID Connect (OIDC)
  • Tokens web JSON (JWTs) autofirmados
  • Blobs binarios autofirmados

Para obtener más información, consulta Crear credenciales de cuenta de servicio de corta duración.

Interpretar los registros de auditoría

Los registros de Cloud te ayudan a responder a las preguntas sobre quién hizo qué, dónde y cuándo en tus Google Cloud recursos.

Cuando usas credenciales de duración reducida para suplantar la identidad de una cuenta de servicio, la mayoría de los servicios deGoogle Cloud crean entradas de registro que muestran las siguientes identidades:

  • La cuenta de servicio que suplantan las credenciales de duración reducida
  • La identidad que ha creado las credenciales de duración reducida

Puedes usar estas entradas de registro para identificar la entidad de seguridad que creó las credenciales de corta duración, así como la cuenta de servicio que suplantó la entidad de seguridad.

Para ver ejemplos de entradas de registro de auditoría que muestran la suplantación de identidad de una cuenta de servicio, consulta Suplantar la identidad de una cuenta de servicio para acceder Google Cloud.

Suplantación de identidad

La suplantación de identidad se produce cuando usas las credenciales de una cuenta de servicio para generar una nueva credencial para esa cuenta.

La API de credenciales de cuentas de servicio prohíbe los siguientes tipos de suplantación de identidad:

Google Cloud prohíbe este tipo de suplantación de identidad porque permite que los agentes maliciosos actualicen los tokens robados indefinidamente.

Si intentas usar la suplantación de identidad de una de las formas prohibidas, es posible que se produzca el siguiente error:

 FAILED_PRECONDITION: You can't create a token for the same service account that you used to authenticate the request. 

Si se produce este error, prueba a usar otras credenciales para generar la nueva credencial de corta duración de tu cuenta de servicio. Por ejemplo, las credenciales de tu usuario final o las de otra cuenta de servicio.

Claves de cuenta de servicio

Cada cuenta de servicio está asociada a un par de claves RSA pública y privada. La API Service Account Credentials usa este par de claves interno para crear credenciales de cuenta de servicio de corta duración y para firmar blobs y tokens web JSON (JWTs). Este par de claves se conoce como Google-owned and managed key par.

Además, puedes crear varios pares de claves RSA públicas y privadas, conocidos como pares de claves gestionados por el usuario, y usar la clave privada para autenticarte en las APIs de Google. Esta clave privada se conoce como clave de cuenta de servicio.

Google-owned and managed key pares

Los paresGoogle-owned and managed key se usan en la API Service Account Credentials y en servicios como Google Cloud App Engine y Compute Engine para generar credenciales de corta duración para cuentas de servicio.

Google-owned and managed keys que se usan activamente para firmar se rotan periódicamente de acuerdo con las prácticas recomendadas de seguridad. El proceso de rotación es probabilístico: el uso de la nueva clave aumentará y disminuirá gradualmente durante el tiempo de vida de la clave.

La clave privada de un par Google-owned and managed key siempre se mantiene en depósito y nunca puedes acceder a ella directamente.

La clave pública de un par es accesible públicamente, de modo que cualquier persona puede verificar las firmas creadas con la clave privada. Google-owned and managed key Puedes acceder a la clave pública en varios formatos:

  • Certificado X.509: 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 y almacenas en caché la clave pública, te recomendamos que la almacenes en caché durante un máximo de 24 horas para asegurarte de que siempre tienes la clave actual. Independientemente de cuándo obtenga la clave pública, será válida durante al menos 24 horas después de obtenerla.

Pares de claves gestionados por el usuario

Puedes crear pares de claves gestionadas por el usuario para una cuenta de servicio y, a continuación, usar la clave privada de cada par de claves para autenticarte en las APIs de Google. Esta clave privada se conoce como clave de cuenta de servicio.

Las bibliotecas de cliente de Cloud pueden usar claves de cuenta de servicio para obtener automáticamente un token de acceso de OAuth 2.0. También puedes usar una clave de cuenta de servicio para firmar un JWT manualmente y, a continuación, usar el JWT firmado para solicitar un token de acceso. Para obtener más información, consulta el artículo sobre cómo usar OAuth 2.0 en aplicaciones de servidor a servidor.

Cada cuenta de servicio puede tener hasta 10 claves. Google solo almacena la parte pública de un par de claves gestionado por el usuario.

Hay varias formas de crear un par de claves gestionado por el usuario para una cuenta de servicio:

Las claves gestionadas por los usuarios son credenciales muy potentes. Para limitar el uso de claves gestionadas por el usuario, puedes aplicar las siguientes restricciones de política de organización en una organización, un proyecto o una carpeta:

  • constraints/iam.disableServiceAccountKeyCreation: impide que las principales creen claves de cuentas de servicio gestionadas por el usuario.
  • constraints/iam.disableServiceAccountKeyUpload: impide que las entidades suban una clave pública para una cuenta de servicio.

Si aplicas estas restricciones porque usas la federación de identidades de cargas de trabajo, considera la posibilidad de usar las restricciones de la política de la organización para la federación de identidades de cargas de trabajo para especificar qué proveedores de identidades están permitidos.

Tiempos de vencimiento de las claves gestionadas por el usuario

De forma predeterminada, cuando creas una clave de cuenta de servicio gestionada por el usuario, la clave nunca caduca. Para cambiar este valor predeterminado, puedes definir un tiempo de vencimiento para todas las claves que se creen en tu proyecto, carpeta u organización. El tiempo de vencimiento especifica el número de horas durante las que es válida una clave recién creada.

Usa tiempos de vencimiento cuando necesites acceso temporal a un sistema que requiera una clave de cuenta de servicio. Por ejemplo, usa tiempos de vencimiento cuando hagas lo siguiente:

  • Desarrollar código en un entorno que no es de producción para una aplicación que solo puede autenticarse con claves de cuentas de servicio
  • Usar una herramienta de terceros que solo pueda autenticarse con claves de cuentas de servicio

No utilice tiempos de vencimiento en los siguientes casos:

  • Cargas de trabajo de producción. En producción, una clave de cuenta de servicio caducada podría provocar una interrupción accidental. En su lugar, usa claves que no caduquen y gestiona su ciclo de vida con la rotación de claves.
  • Cargas de trabajo de no producción que necesitan acceso permanente, como un flujo de integración continua (CI).
  • Sistemas de rotación de claves que impiden que se use una clave después de un periodo especificado. Para obtener información sobre las estrategias de rotación de claves recomendadas, consulta Rotación de claves de cuentas de servicio.

Para evitar interrupciones, te recomendamos que no definas una hora de vencimiento a menos que la constraints/iam.disableServiceAccountKeyCreation restricción de la política de la organización se haya aplicado durante un periodo prolongado. Cuando definas una hora de vencimiento, también debes dejar de aplicar la restricción constraints/iam.disableServiceAccountKeyCreation. Para obtener más información sobre esta restricción, consulta el artículo Limitar el tiempo de validez de las claves de cuentas de servicio.

Para definir una hora de vencimiento, sigue estos pasos:

  1. Identifica el proyecto, la carpeta o la organización en los que quieras definir un tiempo de vencimiento para las claves de cuentas de servicio.
  2. Añade una política de organización que aplique la constraints/iam.serviceAccountKeyExpiryHoursrestricción. Una vez que hayas aplicado esta restricción a tu proyecto, carpeta u organización, el tiempo de vencimiento se aplicará a todas las claves de cuenta de servicio que se creen en ese recurso superior. Las claves que ya tengas no se verán afectadas.

Los tiempos de vencimiento se miden en horas. Como práctica recomendada, utiliza tiempos de vencimiento cortos, como 8 horas, 24 horas (1 día) o 168 horas (7 días). Los tiempos de vencimiento cortos ayudan a que tu equipo tenga un proceso bien probado para actualizar las claves. Empieza con el tiempo de vencimiento más corto que se ajuste a tus necesidades y auméntalo solo si es necesario.