Habilitar Access Manager

Activa Access Manager en los productos Lerian definiendo las variables de entorno de Auth en cada .env para que tus servicios empiecen a hacer cumplir el acceso.

Instalar Access Manager no basta por sí sola. Para empezar a hacer cumplir el acceso, lo activas en cada producto definiendo las variables de Auth en el archivo .env de cualquier producto o plugin Lerian donde lo quieras activo.

Habilitar Access Manager solo activa el cumplimiento de autorización en un producto o plugin. Los datos de acceso los gestionas por separado mediante Access Manager. Esto incluye usuarios, grupos, aplicaciones, proveedores, roles y permisos.

Cada producto protegido debe habilitar el cumplimiento y apuntar a Auth. La variable de dirección no es la misma en todos los repositorios, así que usa la variable que espera el producto que configuras:

Text

# Most products and plugins
PLUGIN_AUTH_ENABLED=true
PLUGIN_AUTH_ADDRESS=http://plugin-auth:4000

Para un producto que admite multi-tenancy BYOC, configura el conjunto completo de variables específicas de ese producto. Para Midaz Ledger, habilitar multi-tenancy también requiere la URL de su Tenant Manager Service y un host de Valkey. Tenant Manager escucha en el puerto 4026 de forma predeterminada:

Text

# Midaz Ledger multi-tenant configuration
MULTI_TENANT_ENABLED=true
MULTI_TENANT_URL=https://tenant-manager.<your-domain>
MULTI_TENANT_REDIS_HOST=valkey

Apunta MULTI_TENANT_URL a un endpoint HTTPS para que MULTI_TENANT_SERVICE_API_KEY no viaje por HTTP en texto plano. El HTTP dentro del clúster (http://tenant-manager.<namespace>.svc.cluster.local:4026) es solo para clústeres locales, fuera de producción, y requiere la activación explícita MULTI_TENANT_ALLOW_INSECURE_HTTP=true.

En despliegues con Helm, Midaz también necesita MULTI_TENANT_SERVICE_API_KEY, que normalmente se entrega mediante un Secret o un Secret existente. El flag por sí solo no es una configuración multi-tenant completa. Sigue la documentación de despliegue del producto que configuras. Si tu SERVER_ADDRESS de Tenant Manager o tu Service de Kubernetes sobrescribe el puerto predeterminado, usa esa dirección desplegada en su lugar.

Después de que habilites Access Manager, las solicitudes de API protegidas deben incluir un header Authorization con un Bearer access token válido.

Sin este header, las solicitudes protegidas se rechazan, incluso en endpoints que antes eran accesibles sin autenticación.

Aprende a generar y usar access tokens.

​

Dónde actualizar

---

Encontrarás los archivos .env relevantes en estas ubicaciones:

• Midaz
  • /midaz/components/ledger usa PLUGIN_AUTH_HOST. El componente CRM usa PLUGIN_AUTH_ADDRESS en su propia configuración.
  • /midaz/components/tracer usa PLUGIN_AUTH_ADDRESS
• Otros productos y plugins
  • Usa el archivo .env en la raíz del producto o del plugin, o en el directorio del componente cuando el repositorio está dividido en componentes.
  • Reporter, Flowker y Bank Transfer usan PLUGIN_AUTH_ADDRESS.
  • Pix Indirect BTG usa PLUGIN_AUTH_ADDRESS en su servicio pix y PLUGIN_AUTH_HOST en sus workers inbound y outbound.
  • Pix via JD usa PLUGIN_AUTH_HOST.

Si no ves los archivos, ajusta la configuración de tu sistema para mostrar los archivos ocultos. Los archivos .env suelen estar ocultos de forma predeterminada.

​

Reconstruye después de los cambios

---

Después de actualizar un archivo .env, reconstruye y reinicia desde la raíz del repositorio que es dueño de ese archivo. Los comandos de ciclo de vida difieren según el repositorio: en la raíz del repositorio de Midaz, ejecuta make rebuild-up, porque su target make up arranca los servicios sin reconstruirlos. Para otros productos y plugins, usa el comando de ciclo de vida documentado en ese repositorio. El código fuente de Access Manager usa los siguientes comandos:

1. En tu terminal, ve a la raíz del repositorio de Access Manager.

2. Si Docker está en ejecución, deténlo:

   Bash

   make down
   
3. Luego construye y arranca el stack:

   Bash

   make up
   

​

Ciclo de vida del despliegue

---

La configuración de Access Manager tiene dos fases, y el bootstrap difiere según el modo de despliegue:

• El bootstrap single-tenant inicializa un entorno nuevo con la organización base, los roles, los grupos, las aplicaciones y los conjuntos de permisos que requiere la plataforma.
• El bootstrap multi-tenant prepara solo el material de certificados compartido. No inicializa organizaciones de tenant, usuarios, grupos, aplicaciones ni conjuntos de permisos. Crea y gestiona los datos de acceso del tenant después de que el tenant existe.
• La operación empieza después de que el entorno esté en marcha. A partir de ese punto, gestiona el acceso mediante las APIs de Identity o Lerian Console.

Usa las APIs operativas para el acceso de usuarios, la asignación de grupos, las credenciales de aplicación, los proveedores y MFA. No cambies un entorno en ejecución editando los archivos de inicialización del bootstrap.

El bootstrap aplica sus datos de inicialización solo durante la configuración inicial del entorno. Los cambios a recursos, acciones, roles, grupos, aplicaciones o conjuntos de permisos integrados en un entorno existente deben entregarse mediante actualizaciones controladas de la plataforma, como migraciones o un conciliador idempotente.