Salta al contenido principal
Imprimir el Libro CompletoImprimir el Libro Completo

Documentación: 2. Arquitectura Stratio GoSec

Sitio: STRATIO Training & Certification
Curso: Stratio Generative AI Data Fabric GOSEC (14.6)
Libro: Documentación: 2. Arquitectura Stratio GoSec
Imprimido por: Invitado
Día: lunes, 1 de junio de 2026, 07:50

Tabla de contenidos

1. Identidades

La gestion de identidades dentro de Stratio Data Fabric se apoya en la siguiente arquitectura:



  • GoSec Identities: Es la API de GoSec para la gestión de identidades y tenants.

  • SIS-Synchronizer: Este servicio únicamente se debe desplegar si, en lugar de autenticar directamente con el LDAP, se quiere delegar la autenticación en un tercero. Actúa como servidor SCIM, es decir, su función es la de aprovisionar los usuarios y grupos necesarios para poder operar la autorización de las aplicaciones y servicios alojados en Stratio.


2. Role Manager

Para la gestión de roles existe una API en gosec-identities-daas con todas las operaciones CRUD sobre los permisos y su asignación a usarios y grupos. Estos endpoints son usados desde gosec-management-baas de dos formas:

  • Gestionar perfilado: un usuario administrador (cluster-owner o tenant-owner) puede asignar permisos a usuarios de manera sencilla desde la sección "Role Manager" de gosec-management.


  • Autenticación y perfilado de gosec-management: en el proceso de autenticación del JWT se realiza una llamada a gosec-identities-daas para consultar que permisos tiene el usuario en el tenant autenticado. Estos datos se almacenarán junto a la ficha del usuario para almacenarlos en el contexto de seguridad de gosec-management-baas que a su vez serán usados para realizar el perfilado de la aplicación.




3. Autenticación

Para el acceso a Stratio Generative AI Data Fabric existe el Stratio-identity-server (SIS), basado en CAS 6.6. 

Este servicio permite autenticar usuarios conectándose directamente a un LDAP/Active directory así como delegar la autenticación a un tercero usando el protocolo SAML.

Acompañando al SIS hay diferentes servicios en los que se apoya para distintas funcionalidades.



  • SIS API: sirve para diferentes operaciones, gestión del MFA, registro de servicios Oauth2 (flujo code) y registro de IdPs SAML2 (tanto en Vault como su publicación en el API de Kubernetes).

  • SIS Operator: A partir de Stratio GoSec 1.13 se añade sis-operator, un operador de Kubernetes que se encarga de la gestión de IdPs federados. Este servicio monitoriza los objetos de tipo Saml2FederatedIdp en el API de Kubernetes para gestionar la reconfiguracion del SIS en caso de que haya un cambio (adición, edición y borrado) en estos objetos.

  • Vault: KMS del producto. En el contexto de autenticación se guardan los tickets, los registros de los servicios Oauth y la configuración del MFA.

  • GoSec Identities Daas: Involucrado en el proceso de autenticación ya que es la dependencia que el SIS usa para persistir información sobre autenticación o recuperar información del usuario.

Otras piezas involucradas en este procesos son el LDAP/AD que se esté usando en la instalación o los IdPs federados integrados.

Con respecto a OAuth, en el ámbito administrativo se usa oauth2-proxy para gestionar el protocolo y es ingress-controller quien genera la credencial (stratio-cookie).

Hay servicios como Stratio Rocket o Stratio Intelligence que se integran de manera directa y gestionan ellos su propia credencial.




3.1. Flujo

El flujo de autenticación es el siguiente:



3.2. Login con certificado

Además de con usuario y contraseña, puedes acceder a la interfaz de usuario de Stratio GoSec con certificados. 

Para servicios ya registrados y disponiendo de certificados, puedes obtener el JWT del mismo modo que en el proceso de autenticación a través de la interfaz.

El SIS deberá estar configurado como balanceador de carga y, si no se indica el tenant, se utilizará keos.



4. Autorización

En el proceso de autorización están involucrados distintos componentes:



4.1. Gosec-Management

Para gestionar todos los aspectos de la autorización desde una interfaz de usuario, en el proceso de instalación del cluster se despliegan estos 2 servicios:

  • Gosec-management-UI: frontend de Gosec-Management.

  • Gosec-management-Baas: su función principal es actuar como backend del frontal. Este servicio usa como credencial una cookie con formato JWT que contiene los datos necesarios para la identificación del usuario y su autorización para usar la API. Esta API se expone hacia fuera del cluster, con lo que podría usarse sin necesitar la interfaz de usuario por cualquier aplicación que consiga una cookie válida.

Para acceder a los datos de identidades, servicios, políticas, BDL, etc., se comunica vía REST con los servicios Gosec-Identities-Daas, Gosec-Services-Daas, Gosec-Authz y Governance (dg-businessglossary-api).

4.2. GoSec Identities

GoSec-Identities proporciona una API CRUD completa de los usuarios, grupos y tenants. 

Esta API REST se consume únicamente por servicios dentro del cluster. Los endpoints están securizados mediante autenticación TLS mutua. Adicionalmente, el servicio valida que el CN esté dentro de una lista configurada.

4.3. GoSec-authz

Este servicio se encarga de gestionar la autorización de la plataforma. Se despliega en el proceso de instalación del cluster.

Ofrece la siguiente API:

  • Autorización: endpoint para ejecutar el proceso de autorización.

  • Filtro de columnas: endpoint para ejecutar el filtro de columnas.

  • Filtro de filas: endpoint del filtrado de filas.

  • Cachés: varios endpoints que devuelven información útil para generar la caché cuando la autorización se realiza en modo local desde la fachada (Dyplon-Facade). Esta API REST se consume únicamente por servicios dentro del cluster. Los endpoints están securizados mediante autenticación TLS mutua. Adicionalmente, el servicio valida que el CN esté dentro de una lista configurada.


4.4. GoSec-services

Para gestionar los servicios de la plataforma y sus políticas, en el proceso de instalación del cluster se despliega gosec-services-daas. 

Este servicio proporciona una API CRUD completa de servicios y políticas. Esta API REST se consume únicamente por servicios dentro del cluster. 

Los endpoints están securizados mediante autenticación TLS mutua. Adicionalmente, el servicio valida que el CN esté dentro de una lista configurada.

Los endpoints de servicios y políticas actualmente los consume Stratio Command Center para realizar el prerregistro de servicios en Stratio GoSec y ejecutar los prerrequisitos de instalación a través de la API CCT-deploy. 

Adicionalmente, las aplicaciones autorizables usan el endpoint de servicios para registrar sus recursos y acciones en Stratio GoSec y sirve las políticas de dominios a la fachada.

El backend usado en los procesos de autorización es PostgreSQL®.


4.5. Autorización

Se aplicarán las políticas de acceso del servicio al que se intenta acceder. 

Hay dos posibles escenarios:

  • Servicios JVM: los servicios implementados con tecnología Java/Scala usarán los métodos de autorización que dispone la fachada. Esta puede funcionar de dos modos:


    • Local (por defecto): la fachada se trae la información de políticas y servicios a una caché de tamaño y tiempo de vida (TTL) configurable para, finalmente, hacer la autorización en local. Para generar la caché, invocará a diferentes endpoints de Stratio GoSec.



  • Remoto: la autorización se ejecuta directamente con una llamada a un endpoint que se encargará de ejecutar toda la lógica. En este caso, el rendimiento es peor ya que implica una llamada REST inviable en escenarios de alta carga/rendimiento.
  • Servicios no JVM: en este caso, es la propia tecnología la que se encarga de obtener las políticas a través de Stratio GoSec para trasladarlas a la tecnología nativa.

El backend utilizado en los procesos de autorización es PostgreSQL®.

4.6. Analítica

Para realizar analítica y ofrecer herramientas que sirvan para tener una visión del estado global de la seguridad, se despliegan los servicios gosec-auth-analytics que, dada su función informacional, en la medida de lo posible no comparten recursos con el resto de servicios operativos.

Direct Query es la herramienta que permite a un operador de seguridad consultar si un usuario tien acceso a un recurso y por qué.

En el caso de una consulta para autorización de recursos clásica, gosec-auth-analytics solo usa el modelo de Stratio GoSec almacenado en la base de datos.

Si la consulta se realiza para ver si un usuario tiene acceso a un elemento de una colección (ya sea la colección en sí, un concepto o una propiedad), gosec-auth-analytics accede a los datos de Stratio Data Governance a través de su API y a los de Stratio GoSec de nuevo contra la base de datos.




4.7. Audit

Esta funcionalidad solo aparecerá disponible si se encuentra desplegado la solución centralizada de logs de Keos basada en el stack EFK que adicionalmente despliega el microservicio gosec-audit-daas. 

Para este caso, en lugar de visualizar y explotar los logs con Kibana intervienen los siguientes elementos que se encargan de además de visualizar, darles una serie de características extras como la categorización, filtrado y exportación de los logs de auditoría separados en categorías funcionales.



  • GoSec-Audit-daas: capa de acceso a datos al OpenSearch, obtiene los datos del índice all-keos-pod-audit-*

  • GoSec-management: interfaz web dividida desplegada con los servicios gosec-management-ui con el frontend y gosec-management-baas como backend. En este caso se añade una sección nueva que aparecerá si responde el endpoint de health de gosec-audit-daas.

  • OpenSearch y Fluentd: elementos usados en la solución de logs para recolectar y procesar los logs de los pods (Fluentd) y persistirlos en OpenSearch.