Skip to content

Desplegando ms-roles: El Corazón del Control de Acceso

Continuando con el despliegue de nuestro ecosistema, llegamos a un componente fundamental para la seguridad y la autorización: ms-roles. Este microservicio tiene una responsabilidad única y crítica: gestionar la creación, actualización y eliminación de los Roles dentro de nuestra aplicación.

Un “Rol” define un conjunto de permisos (ej. “Administrador”, “Editor”, “Lector”). ms-roles actúa como la fuente de verdad para estos roles, asegurando que estén definidos de manera consistente en toda la plataforma.

Fiel a nuestro arquetipo, ms-roles sigue una arquitectura limpia y predecible.

Este diagrama muestra cómo las peticiones REST se traducen en acciones internas.

Diagrama de Flujo CQRS de ms-roles
  • Peticiones REST: La API expone endpoints CRUD estándar para gestionar la entidad Role.
  • Casos de Uso: La lógica está separada en Commands (operaciones de escritura que emiten eventos como RoleCreated) y Queries (operaciones de solo lectura).

La lógica de negocio está encapsulada en el RoleAggregate.

Diagrama de Agregado de Dominio de ms-roles

El Agregado RoleAggregate contiene las propiedades de un rol (como Name y Description) y los métodos que garantizan la consistencia y validan las reglas de negocio en cada operación.

  1. Configurando los Secretos en Vault ms-roles necesita las credenciales base para conectarse a RabbitMQ, Redis y MongoDB.

    Terminal window
    vault kv put -mount=inventory-keyvalue ms-roles `
    "RabbitMQ:UserName=<USERNAME_FROM_RABBITMQ_SECRET>" `
    "RabbitMQ:Password=<PASSWORD_FROM_RABBITMQ_SECRET>" `
    "Redis:Instances:Core:ConnectionString=<CONNECTION_STRING_FROM_REDIS>" `
    "Mongo:ConnectionString=<VAULT_TRANSIT_PASSWORD>"
    Creando los secretos para ms-roles en Vault

    Verificamos que los secretos se hayan guardado correctamente en la interfaz web de Vault.

    Verificando los secretos de ms-roles en la UI de Vault
  2. Desplegando con Helm desde ArtifactHub ms-roles solo expone una API REST, por lo que desplegaremos un único Helm Chart.

    • Preparar el values-rest.yaml Local Creamos un archivo values-rest.yaml con la configuración de las variables de entorno no sensibles y la conexión a Vault.

      # values-rest.yaml para ms-roles-rest
      ms-base:
      env:
      - name: RESOURCES__ENABLE
      value: "true"
      - name: RESOURCES__SERVER
      value: "http://ms-services-grpc.inventory.svc.cluster.local:5001"
      - name: SECURITY__VALIDISSUER
      value: "https://devcodedesignplus.ciamlogin.com/dfee7752-2c8a-4171-ad95-62ddc82d6ed8/v2.0/"
      - name: SECURITY__CLIENTID
      value: "305f759d-d1d2-467b-9eab-4a61389c7329"
      - name: SECURITY__VALIDAUDIENCES__0
      value: "305f759d-d1d2-467b-9eab-4a61389c7329"
      - name: RABBITMQ__HOST
      value: "rabbitmq-cluster.srv-rabbitmq.svc"
      - name: LOGGER__OTELENDPOINT
      value: "http://inventory-opentelemetry-collector.otel-inventory.svc.cluster.local:4317"
      - name: OBSERVABILITY__SERVEROTEL
      value: "http://inventory-opentelemetry-collector.otel-inventory.svc.cluster.local:4317"
      vault:
      server: http://vault.vault.svc.cluster.local:8200
      solution: inventory
      token: ANGq0*B2acD1n5%F
      virtualService:
      create: true
      namespace: istio-ingress
      hosts:
      - services.codedesignplus.app
      gateways:
      - istio-ingress/istio-inventory-gateway
      http:
      - name: ms-roles
      match:
      - uri:
      prefix: /ms-roles/
      rewrite:
      uri: /
      route:
      - destination:
      host: ms-roles-rest.inventory.svc.cluster.local
      port:
      number: 5000
    • Ejecutar el Despliegue con Helm Usamos helm upgrade --install para desplegar el chart en el namespace inventory.

      Terminal window
      helm upgrade --install ms-roles-rest codedesignplus/ms-roles-rest -f ./values-rest.yaml --namespace inventory
      Instalando el Helm chart de ms-roles-rest
  1. Verificar el Pod en Lens En Lens, bajo “Workloads > Pods”, ahora vemos nuestro nuevo pod ms-roles-rest corriendo en el namespace inventory.

    Verificando el pod de ms-roles en Lens
  2. Verificar el VirtualService de Istio El Helm chart ha creado automáticamente el VirtualService que enruta el tráfico desde nuestro Gateway. En Lens, bajo “Custom Resources > VirtualService”, podemos ver la nueva regla para ms-roles-rest.

    Verificando el VirtualService de ms-roles en Lens
  3. Probar el Acceso a la API

    • Endpoint de Salud: Verificamos que el servicio está vivo accediendo a su endpoint de salud: https://services.codedesignplus.app/ms-roles/health/ready

      Deberías ver una respuesta “Healthy”.

      Petición exitosa al endpoint de salud de ms-roles
    • Swagger UI: Para explorar la API de forma interactiva, usamos la interfaz de Swagger UI: https://services.codedesignplus.app/ms-roles/index.html

      Aquí puedes ver todos los endpoints disponibles para gestionar los Roles del sistema.

      Visualizando Swagger UI de ms-roles-rest

Has desplegado con éxito ms-roles, sentando una de las bases más importantes para la seguridad y autorización de tu aplicación. Este microservicio no solo gestiona los roles, sino que también demuestra el poder de una arquitectura orientada a eventos al integrarse de forma asíncrona con otros componentes del ecosistema como ms-microsoft-graph.

Cada microservicio que añadimos enriquece la funcionalidad global de la plataforma. En el próximo artículo, continuaremos construyendo sobre esta base, desplegando el microservicio que consumirá estos roles para aplicar permisos: ms-rbac.