Tema 2 de 3
Cuentas de servicio
El apartado 4.2 del temario trata de gestionar cuentas de servicio: crearlas, darles los permisos mínimos, asociarlas a recursos, controlar quién puede usarlas y evitar las claves. La suplantación y Workload Identity Federation se ven en el siguiente artículo.
Contenido
- Qué es una cuenta de servicio
- Tipos: gestionadas, predeterminadas y agentes de servicio
- Principal y recurso a la vez
- Roles sobre cuentas de servicio
- Crear, desactivar y borrar
- Asociar una cuenta de servicio a una VM
- Claves de cuentas de servicio
- Qué método de autenticación usar
- Escenarios de examen
- Trampas frecuentes del examen
Qué es una cuenta de servicio
Una cuenta especial que usa una aplicación o carga de trabajo, no una persona. Se identifica por su correo, con el formato NOMBRE@PROJECT_ID.iam.gserviceaccount.com. Lo más habitual es asociarla al recurso que ejecuta la aplicación (por ejemplo, una VM): el código obtiene credenciales de corta duración automáticamente con Application Default Credentials.
- Cada cuenta vive en un proyecto y no se puede mover a otro.
- Si la cuenta está en un proyecto y accede a recursos de otro, normalmente hay que habilitar la API en los dos proyectos.
- No pertenecen al dominio de Google Workspace: lo que compartes con todo el dominio no se comparte con ellas.
Tipos: gestionadas, predeterminadas y agentes de servicio
| Tipo | Detalle |
|---|---|
| Gestionadas por el usuario | Las creas y gestionas tú. Son las que se usan como identidad de las cargas de trabajo |
| Predeterminadas | Gestionadas por el usuario pero creadas automáticamente al habilitar ciertos servicios: Compute Engine (PROJECT_NUMBER-compute@developer.gserviceaccount.com) y App Engine (PROJECT_ID@appspot.gserviceaccount.com). Su gestión es responsabilidad tuya |
| Agentes de servicio | Creados y gestionados por Google para que un servicio actúe en tu nombre. No están en tu proyecto ni se usan directamente. En la página de IAM se ven marcando Include Google-provided role grants |
La cuenta predeterminada de Compute Engine
Se asocia por defecto a las VMs creadas con la consola o gcloud y, según la política de la organización, puede recibir el rol Editor en el proyecto. Google recomienda encarecidamente aplicar la restricción iam.automaticIamGrantsForDefaultServiceAccounts (activa por defecto en organizaciones creadas desde el 3 de mayo de 2024) y sustituir Editor por roles menos permisivos, usando Policy Simulator para ver el impacto.
Principal y recurso a la vez
Como principal
Se le conceden roles sobre recursos, como a cualquier principal: serviceAccount:SA_EMAIL. También se pueden usar conjuntos de principales para todas las cuentas de servicio de un proyecto, carpeta u organización.
Como recurso
Tiene su propia allow policy, que decide quién puede usarla, suplantarla o administrarla. Quien puede actuar como ella accede a todo lo que ella puede acceder.
# La cuenta como principal: puede leer objetos del bucket gcloud storage buckets add-iam-policy-binding gs://app-data \ --member=serviceAccount:app-sa@my-project.iam.gserviceaccount.com \ --role=roles/storage.objectViewer # La cuenta como recurso: un usuario puede asociarla a recursos gcloud iam service-accounts add-iam-policy-binding \ app-sa@my-project.iam.gserviceaccount.com \ --member=user:dev@example.com --role=roles/iam.serviceAccountUser
Roles sobre cuentas de servicio
| Rol | Qué permite |
|---|---|
Service Account Userroles/iam.serviceAccountUser | Asociar la cuenta a recursos (VMs, servicios de Cloud Run…). Incluye iam.serviceAccounts.actAs |
Service Account Token Creatorroles/iam.serviceAccountTokenCreator | Suplantar la cuenta: crear tokens de corta duración en su nombre |
Service Account Adminroles/iam.serviceAccountAdmin | Ver, editar, desactivar y borrar la cuenta de servicio |
Create Service Accountsroles/iam.serviceAccountCreator | Crear cuentas de servicio |
Google recomienda conceder estos roles sobre la cuenta de servicio concreta y no en el proyecto o la carpeta: Token Creator en el proyecto dejaría suplantar a todas las cuentas del proyecto.
Crear, desactivar y borrar
gcloud iam service-accounts create app-sa \ --description="Orders API" --display-name="orders-api" gcloud iam service-accounts disable app-sa@my-project.iam.gserviceaccount.com gcloud iam service-accounts enable app-sa@my-project.iam.gserviceaccount.com gcloud iam service-accounts delete app-sa@my-project.iam.gserviceaccount.com gcloud beta iam service-accounts undelete ACCOUNT_ID
- El ID tiene entre 6 y 30 caracteres (minúsculas, números y guiones). El nombre visible sirve para documentar su uso y responsable.
- Buenas prácticas: una cuenta por aplicación (los logs de auditoría muestran la cuenta, no la aplicación), convención de nombres y mínimo privilegio.
- Desactiva antes de borrar: una cuenta desactivada se puede reactivar si resulta que se usaba. Las insights de cuentas de servicio y Activity Analyzer ayudan a encontrar las que no se usan (90 días sin autenticarse).
- Una cuenta borrada se puede recuperar durante 30 días. Si creas otra con el mismo nombre, no hereda sus vinculaciones ni asociaciones, porque IAM usa un ID numérico único.
- La restricción
iam.disableServiceAccountCreationimpide crear cuentas de servicio en una organización, carpeta o proyecto.
Asociar una cuenta de servicio a una VM
Google recomienda crear una cuenta gestionada por el usuario con solo los roles necesarios y asociarla a la VM. Solo puede haber una cuenta por VM. Para cambiarla, la VM tiene que estar parada.
gcloud compute instances stop app-vm --zone=europe-west1-b gcloud compute instances set-service-account app-vm --zone=europe-west1-b \ --service-account=app-sa@my-project.iam.gserviceaccount.com \ --scopes=cloud-platform gcloud compute instances start app-vm --zone=europe-west1-b
Ámbitos de acceso (access scopes)
Son el método heredado de autorización de una VM. El acceso real es la intersección de los roles de la cuenta y los ámbitos. Los ámbitos por defecto dan, entre otros, solo lectura a Cloud Storage y escritura de logs y métricas. La práctica recomendada es usar el ámbito completo cloud-platform y controlar el acceso con roles de IAM.
Para asociar una cuenta de otro proyecto, la restricción iam.disableCrossProjectServiceAccountUsage no debe estar aplicada en el proyecto de la cuenta.
Claves de cuentas de servicio
Una clave permite autenticarse como la cuenta desde cualquier sitio, así que es un riesgo de seguridad si no se gestiona bien. Google pide usar una alternativa más segura siempre que se pueda.
gcloud iam service-accounts keys create key.json \ --iam-account=app-sa@my-project.iam.gserviceaccount.com gcloud iam service-accounts keys delete KEY_ID \ --iam-account=app-sa@my-project.iam.gserviceaccount.com
- Hasta 10 claves por cuenta. Por defecto no caducan; se puede configurar una caducidad para las nuevas, pero Google no la recomienda en producción (mejor rotarlas).
iam.disableServiceAccountKeyCreationbloquea la creación de claves; está activa por defecto en organizaciones creadas desde el 3 de mayo de 2024.- Con la restricción de respuesta a exposición de claves en
DISABLE_KEY, Google desactiva automáticamente las claves filtradas que detecta. - No subas claves a repositorios, no las pases entre usuarios, no las dejes en carpetas temporales ni las incrustes en binarios. Google tampoco recomienda guardarlas en Secret Manager.
Qué método de autenticación usar
| Dónde se ejecuta el código | Método recomendado |
|---|---|
| Tu estación de trabajo o Cloud Shell | Tus credenciales de usuario, o suplantar una cuenta de servicio si la necesitas |
| Google Cloud (VM, Cloud Run…) | Asociar una cuenta de servicio al recurso |
| GKE | Workload Identity Federation for GKE |
| On-premises u otra nube con un IdP compatible | Workload Identity Federation |
| Ninguna de las anteriores | Clave de cuenta de servicio (último recurso) |
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| Una aplicación en una VM debe leer objetos de un bucket | Cuenta de servicio propia con roles/storage.objectViewer asociada a la VM | Mínimo privilegio; sin claves. |
| Un desarrollador debe poder crear VMs que usen una cuenta de servicio concreta | roles/iam.serviceAccountUser sobre esa cuenta de servicio | Incluye iam.serviceAccounts.actAs. |
| Cambiar la cuenta de servicio de una VM existente | Parar la VM y usar gcloud compute instances set-service-account | Solo una cuenta por VM. |
| La cuenta predeterminada de Compute Engine tiene Editor | Sustituir Editor por roles mínimos y aplicar iam.automaticIamGrantsForDefaultServiceAccounts | Google lo recomienda encarecidamente. |
| Retirar una cuenta de servicio que parece sin uso | Desactivarla primero y borrarla cuando se confirme | Una desactivada se puede reactivar. |
| Borraste por error una cuenta de servicio hace 10 días | Recuperarla con undelete | Hasta 30 días; recrearla con el mismo nombre no recupera sus permisos. |
| Impedir que se creen claves de cuentas de servicio en la organización | Restricción iam.disableServiceAccountKeyCreation | Activa por defecto en organizaciones creadas desde el 3 de mayo de 2024. |
| Un pod de GKE debe llamar a APIs de Google | Workload Identity Federation for GKE | No hacen falta claves. |
Trampas frecuentes del examen
❓ ¿Service Account User o Token Creator para que alguien asocie una cuenta a una VM?
Service Account User (actAs). Token Creator sirve para suplantarla y obtener tokens.
❓ ¿Se puede cambiar la cuenta de servicio de una VM en ejecución?
No. Hay que pararla, ejecutar set-service-account y volver a arrancarla.
❓ ¿Recrear una cuenta borrada con el mismo correo recupera sus permisos?
No. Tiene otro ID único y las vinculaciones antiguas no le aplican. Usa undelete dentro de los 30 días.
❓ ¿Basta con el ámbito de acceso para restringir lo que hace una VM?
Es el método heredado. Google recomienda el ámbito cloud-platform y controlar el acceso con roles de IAM.
❓ ¿Las claves de cuentas de servicio caducan solas?
No por defecto. Hay que rotarlas o borrarlas; mejor evitarlas.
❓ ¿Se puede mover una cuenta de servicio a otro proyecto?
No. Para usarla en otro proyecto se asocia entre proyectos o se suplanta.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación en Compute Engine debe publicar mensajes en un tema de Pub/Sub. Ahora usa la cuenta predeterminada de Compute Engine, que tiene el rol Editor. ¿Qué es lo más seguro?
¿Listo para poner a prueba "Cuentas de servicio"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro