Habilitación de Access Manager

Activa Access Manager en los productos Lerian — define las variables de Auth en cada .env para que tus servicios empiecen a aplicar el control de acceso.

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

Habilitar Access Manager solo activa la aplicación de la autorización en un producto o plugin. Los datos de acceso, como usuarios, grupos, aplicaciones, proveedores, roles y permisos, se gestionan por separado a través de Access Manager.

Cada producto protegido debe habilitar la validación 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 estás configurando:

Text

# Mayoría de productos y 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ífico del producto. Para Midaz Ledger, habilitar multi-tenancy también requiere la URL de su servicio Tenant Manager y un host de Valkey. Tenant Manager escucha en el puerto 4026 de forma predeterminada:

Text

# Configuración multi-tenant de Midaz Ledger
MULTI_TENANT_ENABLED=true
MULTI_TENANT_URL=https://tenant-manager.<tu-dominio>
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 claro. El HTTP dentro del clúster (http://tenant-manager.<namespace>.svc.cluster.local:4026) es solo para clústeres locales, no productivos, y requiere el opt-in explícito MULTI_TENANT_ALLOW_INSECURE_HTTP=true.

En despliegues 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 completa la configuración multi-tenant; sigue la documentación de despliegue del producto que estés configurando. Si SERVER_ADDRESS o el Service de Tenant Manager anula el puerto predeterminado, usa esa dirección desplegada.

Una vez que Access Manager esté habilitado, las solicitudes a APIs protegidas deben incluir un encabezado Authorization con un Bearer access token válido.

Sin este encabezado, las solicitudes protegidas serán rechazadas, incluso para endpoints que antes eran accesibles sin autenticación.

Aprende cómo 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 plugin, o en el directorio del componente cuando el repositorio esté dividido en componentes.
  • Reporter, Flowker, Bank Transfer y Fetcher 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 Directo JD usa PLUGIN_AUTH_HOST.

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

​

Reconstruir después de los cambios

---

Después de actualizar un archivo .env, reconstruye y reinicia desde la raíz del repositorio que contiene ese archivo. Los comandos de ciclo de vida cambian según el repositorio: en la raíz del repositorio de Midaz, ejecuta make rebuild-up, porque su objetivo make up inicia 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, detenlo:

   Bash

   make down
   
3. Después, construye e inicia el stack:

   Bash

   make up
   

​

Ciclo de vida del despliegue

---

La configuración de Access Manager tiene dos fases, y el bootstrap varía según el modelo de despliegue:

• Bootstrap single-tenant prepara un entorno nuevo con la organización, roles, grupos, aplicaciones y conjuntos de permisos base que requiere la plataforma.
• Bootstrap multi-tenant prepara solo el material de certificado compartido. No siembra organizaciones, usuarios, grupos, aplicaciones ni conjuntos de permisos de tenant; crea y gestiona los datos de acceso del tenant después de que exista el tenant.
• Operación comienza cuando el entorno está en ejecución. A partir de ese punto, gestiona el acceso a través de las APIs de Identity o Lerian Console.

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

Los datos semilla del bootstrap solo se aplican durante la configuración inicial del entorno. Los cambios en recursos, acciones, roles, grupos, aplicaciones o conjuntos de permisos integrados de un entorno existente deben entregarse mediante actualizaciones controladas de la plataforma, como migraciones o un reconciliador idempotente.