Gestión de Identidades y Acceso (IAM)
La Gestión de Identidades y Acceso (IAM) es el pilar que responde a la pregunta: ¿Quién puede hacer qué en nuestros sistemas? En HERA, centralizamos la gestión de identidades y aplicamos el principio de privilegio mínimo para asegurar que los usuarios y servicios tengan únicamente los permisos que necesitan.
Arquitectura de Identidad
Sección titulada «Arquitectura de Identidad»Nuestro modelo de identidad es centralizado para simplificar la gestión y fortalecer la seguridad.
- Proveedor de Identidad (IdP): Google Workspace es nuestra única fuente de verdad para las identidades de los usuarios. Todas las cuentas de usuario, grupos y políticas de autenticación se gestionan aquí.
- Single Sign-On (SSO): Todas las herramientas clave del ecosistema HERA (GitLab, GCP, SonarQube, etc.) están integradas con Google Workspace a través de SSO (
SAML/OIDC). Esto significa que te autenticas una vez con tu cuenta de Google y obtienes acceso a todas las aplicaciones para las que estás autorizado. - Autenticación Multifactor (MFA): El MFA es obligatorio para todos los usuarios, sin excepción. Utilizamos métodos seguros como llaves de seguridad FIDO2 o Google Authenticator.
Arquitectura de Identidad HERA
Identity Provider (IdP)
Google Workspace
Directorio de Usuarios y Grupos Single Sign-On (SSO · SAML/OIDC) MFA Obligatorio (FIDO2 / TOTP)
Provee Identidad Verificada
GitLab HERA
SSO + RBAC
GCP IAM
SSO + Workload Identity
SonarQube y más
SSO centralizado
Principio de Privilegio Mínimo: Los permisos se asignan a grupos, no a usuarios individuales. Nunca se otorgan roles de
Editor u Owner de forma general. Mensaje clave Google Workspace es la fuente única de identidad. SSO + MFA obligatorio para todos los usuarios.
Control de Acceso Basado en Roles (RBAC)
Sección titulada «Control de Acceso Basado en Roles (RBAC)»Los permisos no se asignan a usuarios individuales. Se asignan a roles, y los usuarios son asignados a esos roles, generalmente a través de grupos.
Roles en GitLab HERA
Sección titulada «Roles en GitLab HERA»| Rol | Quién lo tiene | Permisos clave |
|---|---|---|
| Owner | Tech Lead, PM | Control total del proyecto (configuración, miembros). |
| Maintainer | Desarrolladores Senior | Puede hacer merge a ramas protegidas (main). |
| Developer | Desarrolladores | Puede hacer push a ramas de feature y crear MRs. |
| Reporter | QA, Stakeholders | Acceso de solo lectura al código y a los issues. |
Roles en GCP
Sección titulada «Roles en GCP»| Rol | Quién lo tiene | Permisos clave |
|---|---|---|
roles/viewer | Desarrolladores | Puede ver recursos y logs. No puede modificar nada. |
roles/container.developer | Service Account del Pipeline | Puede desplegar a GKE. |
roles/secretmanager.secretAccessor | Aplicaciones en GKE | Puede leer secretos desde Secret Manager. |
Service Accounts (Cuentas de Servicio)
Sección titulada «Service Accounts (Cuentas de Servicio)»Las Service Accounts son identidades para nuestras aplicaciones y pipelines, no para personas.
Buenas Prácticas
Sección titulada «Buenas Prácticas»- Una por Aplicación: Cada aplicación o microservicio tiene su propia Service Account con permisos mínimos.
- No usar Claves: Se prohíbe la creación y descarga de claves JSON. En su lugar, usamos Workload Identity.
Workload Identity: El Estándar para GKE
Sección titulada «Workload Identity: El Estándar para GKE»Workload Identity es el método recomendado por Google y obligatorio en HERA para permitir que tus aplicaciones dentro de GKE accedan a otros servicios de GCP (como Secret Manager o Cloud SQL).
- ¿Cómo funciona? Vincula una Service Account de Kubernetes (KSA) con una Service Account de IAM de GCP (GSA). Cuando tu pod usa la KSA, automáticamente adquiere los permisos de la GSA sin necesidad de ninguna clave.
- ¿Por qué es más seguro? Elimina por completo la necesidad de gestionar, rotar y proteger archivos de claves, que son un riesgo de seguridad masivo.
Ciclo de Vida de Acceso (Onboarding / Offboarding)
Sección titulada «Ciclo de Vida de Acceso (Onboarding / Offboarding)»El acceso se gestiona de forma centralizada y está ligado al ciclo de vida del empleado.
- Onboarding: Cuando un nuevo empleado se une, se le asigna a los grupos de Google correctos según su rol. Estos grupos le otorgan automáticamente los permisos necesarios en GitLab, GCP y otras herramientas.
- Cambio de Rol: Si un empleado cambia de rol, simplemente se actualiza su membresía de grupo.
- Offboarding: Cuando un empleado deja la empresa, su cuenta de Google Workspace se deshabilita, revocando inmediatamente todo su acceso a todos los sistemas integrados.
- Revisión Periódica: Cada 90 días, se realiza una revisión de acceso para asegurar que los permisos sigan siendo los correctos y eliminar accesos innecesarios.