Cuentas de servicio y sus llaves

Una cuenta de servicio puede autenticarse de dos maneras. La buena es sin secretos: el recurso (una máquina, una función) tiene la cuenta adjunta y Google le entrega credenciales temporales. La otra es una llave, un archivo con una clave privada que se descarga y se guarda donde sea. Las llaves creadas por el usuario no vencen por defecto: su fecha de validez llega hasta el año 9999.

Eso convierte una llave en una credencial permanente que se copia, se manda por correo, se sube a un repositorio y no se entera nadie. Por eso las revisiones cuentan cuántas llaves de usuario existen, cuántas pasan de 90 días y quién las creó. Las llaves que gestiona el propio Google (marcadas como SYSTEM_MANAGED) rotan solas y no son el problema.

Abre el laboratorio. llaves.json lista las llaves de las cuentas del proyecto de datos, con keyType (USER_MANAGED las crea una persona; SYSTEM_MANAGED las gestiona Google) y validAfterTime, el momento de creación. La revisión es del 12 de octubre de 2028. La antigüedad se cuenta desde validAfterTime hasta esa fecha, y la regla común de rotación es 90 días.

Cuenta solo las llaves de tipo USER_MANAGED con más de 90 días.

Cuando se activa la API de Cómputo en un proyecto, Google crea una cuenta de servicio por defecto, con el número del proyecto en el correo. En organizaciones antiguas esa cuenta recibe automáticamente el rol editor en el proyecto, un permiso amplísimo que queda para cualquier máquina que la use. Hay una restricción de la organización que evita ese otorgamiento automático (iam.automaticIamGrantsForDefaultServiceAccounts), y se aplica por defecto en las organizaciones creadas desde el 3 de mayo de 2024.

Abre cuentas-de-servicio.txt: la de tipo «por defecto» es fácil de reconocer.

Dos roles de la política de una cuenta de servicio se confunden. roles/iam.serviceAccountUser permite adjuntar la cuenta a un recurso, por ejemplo lanzar una máquina que corre con esa identidad. roles/iam.serviceAccountTokenCreator permite suplantar: pedir credenciales a nombre de la cuenta y actuar como ella. Cualquiera que pueda suplantar a una cuenta tiene, de hecho, todos sus permisos.

En la política de la cuenta de ETL de ventas, busca a quién se concedió la suplantación.

La organización decide que ninguna cuenta de servicio vuelva a tener llaves nuevas creadas por personas. Existen varias restricciones de la política de la organización relacionadas con las llaves: una impide crearlas, otra impide subir llaves propias, otra fija cuántas horas puede durar una llave nueva. Abre restricciones-de-la-organizacion.txt: hoy ninguna está aplicada.