Modelo de seguridad

Aislamiento entre organizaciones

• Base de datos: cada fila pertenece a una organización y PostgreSQL aplica Row-Level Security en modo fail-closed: si una consulta no declara a qué organización pertenece, no ve nada.
• Kubernetes: cada organización tiene su propio namespace de CI con cuotas de recursos, y sus apps corren en namespaces etiquetados como suyos. Una organización no puede desplegar en un namespace de otra.
• Nodos dedicados: las cargas de las organizaciones corren en un pool de nodos separado del de la plataforma. Una política de admisión rechaza cualquier pod de una organización que intente salirse de ese pool.

Credenciales

• Secretos e integraciones se cifran con AES-256-GCM y no se vuelven a mostrar.
• Las credenciales llegan a cada paso por un Secret efímero de Kubernetes que se borra al terminar; nunca van en la definición del Job.
• Las URLs que configuras (Sonar, Jenkins, clusters…) se validan contra SSRF: no pueden apuntar a direcciones internas de la plataforma.

Builds sin privilegios

Las imágenes se construyen con Kaniko: sin daemon de Docker, sin contenedores privilegiados y sin acceso al socket del nodo.

Acceso

• Autenticación con usuario y contraseña o SSO (OIDC).
• Permisos por rol (ver Roles y permisos).
• Gates de aprobación con registro de quién pidió y quién aprobó.

Escaneo continuo

Cada build puede escanear dependencias (Trivy FS), código (SonarQube) e imagen (Trivy) antes de que la release exista.