Las claves de cuenta de servicio son la credencial que se filtra en GCP. Así dejas de crearlas

Una clave de cuenta de servicio de Google Cloud es un fichero JSON con una clave privada que no caduca, no está atada a ninguna red y autentica como la cuenta de servicio desde cualquier punto de internet. Acaba en una variable de CI, en la carpeta de Descargas de alguien, en un hilo de Slack y finalmente en un repositorio público.

Todas las revisiones de seguridad de GCP que hacemos encuentran claves. La pregunta útil no es "¿tienes?" sino "¿puedes dejar de necesitarlas?", y en 2026 la respuesta es casi siempre sí.

Sustituye claves por federación, en este orden

Pipelines de CI/CD — Workload Identity Federation. GitHub Actions, GitLab, Bitbucket y Azure DevOps pueden presentar un token OIDC que GCP intercambia por un token de acceso de vida corta. Creas un pool de identidad de carga, un proveedor para tu sistema de CI y una condición de atributos que lo fije a tu repositorio y rama. Esa última parte importa: un proveedor sin condición de atributos aceptará un token de cualquier repositorio de esa plataforma de CI, que es peor posición que la clave que sustituiste.

La migración es alrededor de una hora por pipeline, y borra la categoría entera.

Cargas en GKE — Workload Identity. Los pods asumen una cuenta de servicio de Kubernetes ligada a una de Google. Sin clave, sin trucos con el servidor de metadatos, sin secreto que rotar. Actívalo en el clúster y los pools de nodos, anota la cuenta de servicio de Kubernetes y quita el fichero de clave montado.

Humanos — suplantación, no claves. Un desarrollador que necesite ejecutar un script como cuenta de servicio usa --impersonate-service-account, que acuña un token de una hora y deja una traza de auditoría con su propia identidad. El permiso para suplantar (roles/iam.serviceAccountTokenCreator) es en sí mismo una concesión auditable, que es exactamente lo que quieres.

Cargas fuera de Google Cloud — también federación. AWS, Azure y cualquier proveedor de identidad compatible con OIDC pueden federarse en GCP. Los sistemas locales sin proveedor de identidad son el caso restante legítimo para claves; acota esas cuentas de servicio a un solo proyecto y rótalas en un calendario que cumplas de verdad.

Después, cierra la puerta

iam.disableServiceAccountKeyCreation como restricción de política de organización, con las excepciones listadas a nivel de carpeta para los pocos sistemas heredados que las necesiten. Acompáñala de iam.disableServiceAccountKeyUpload. Sin la restricción, las claves vuelven en un trimestre, porque la consola hace que crear una sean dos clics y el mensaje de error cuando falla un pipeline lo sugiere.

IAM Conditions: el control infrautilizado

Cuando las credenciales son de vida corta, las condiciones te permiten estrechar lo que pueden hacer sin escribir roles personalizados.

• Acceso con caducidad. Una concesión con request.time < timestamp("2026-10-01T00:00:00Z") expira sola. Así debería funcionar el acceso elevado temporal: el acceso del contratista no necesita un ticket de baja porque se detiene por su cuenta.
• Bindings acotados a recurso. resource.name.startsWith("projects/_/buckets/prod-informes") convierte un Storage Admin de proyecto entero en admin de un bucket.
• Condiciones por etiqueta para conceder acceso a todo lo marcado con un entorno dado, lo que escala mejor que enumerar recursos.

Las condiciones no se aplican a todos los servicios, así que comprueba el soporte antes de apoyarte en una como frontera de seguridad en lugar de como comodidad.

Los hallazgos que se repiten

En las revisiones de GCP aparecen casi siempre cuatro cosas:

• roles/editor en la cuenta de servicio de compute por defecto. Todas las VM del proyecto corren como ella por defecto, así que cualquier ejecución de código en cualquier VM es acceso de escritura a todo el proyecto. Desactiva la concesión automática con la restricción iam.automaticIamGrantsForDefaultServiceAccounts y da a cada carga su propia cuenta de servicio.
• roles/owner concedido a personas en lugar de a un grupo de emergencia con condición y alerta.
• Cuentas de servicio con roles/iam.serviceAccountTokenCreator sobre sí mismas o sobre cuentas más privilegiadas, que es una vía de escalada de privilegios que los escáneres se pierden con frecuencia.
• Claves de más de un año que ningún log de auditoría muestra en uso. Esas se pueden borrar sin más — mira antes los logs de acceso a datos de iam.googleapis.com.

Cubrimos las cuatro en el diagnóstico de seguridad, y los escáneres open source de nuestro artículo de herramientas marcan la primera y la última sin licencia ninguna.

Qué hacer esta semana

Lista todas las claves de cuenta de servicio de la organización: gcloud iam service-accounts keys list en todos tus proyectos, filtrando por claves gestionadas por el usuario. Para cada una, anota qué la usa. Las que nadie sepa son las primeras que hay que borrar, y las de CI son una hora cada una de sustituir.