> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Instalar Access Manager

> Prepara tu entorno, despliega los servicios Auth e Identity y deja Access Manager listo antes de que cualquier producto de Lerian aplique el control de acceso.

Instalar Access Manager significa poner en marcha los servicios **Auth** e **Identity**, conectarlos a sus dependencias y dejarlos listos para responder decisiones de acceso. Es el paso que debe ocurrir *antes* de que cualquier producto de Lerian pueda aplicar autenticación o permisos.

Esta guía está escrita para operadores que están configurando el entorno. Explica qué cubre realmente la instalación, qué necesitas tener disponible y en qué orden levantar las cosas. Para los comandos del Helm chart y la configuración a nivel de chart, sigue la página [Access Manager con Helm](/es/platform/helm/access-manager/access-manager-helm).

## Requisitos previos

***

No necesitas dominar Kubernetes a fondo para planificar una instalación, pero sí necesitas una imagen clara de las piezas involucradas. Trata la lista de abajo como una checklist antes de empezar.

### Licencia

Access Manager es una funcionalidad Enterprise y requiere una configuración de licencia válida de Lerian. Los servicios aplican comprobaciones de licencia mediante middleware HTTP, así que valida la licencia antes de habilitar productos protegidos. Consulta la [documentación de licencia](/es/reference/lerians-license) para más detalles. Si aún no tienes una licencia, [ponte en contacto con nuestro equipo](https://lerian.studio/contact).

### Modelo de despliegue

Decide cómo vas a ejecutar Access Manager. La elección determina la resolución de tenant, la configuración de Casdoor y algunos valores operativos por defecto más adelante.

* **SaaS** - Lerian ejecuta la plataforma; los flujos de acceso se acotan por tenant a partir de claims confiables del JWT.
* **BYOC multi-tenant** - Tú ejecutas Access Manager, y el contexto de tenant proviene de claims confiables del token, nunca de payloads o headers de la solicitud.
* **BYOC single-tenant** - Ejecutas Access Manager contra una organización por defecto configurada y un backend de identidad Casdoor.

Si no estás seguro de qué modelo aplica, confírmalo con tu contacto de Lerian antes de instalar.

### Servicio Auth

El lado de ejecución de Access Manager: emite y renueva tokens, valida sesiones, verifica permisos, gestiona el logout y la información de usuario, y ejecuta los desafíos de MFA. Auth debe ser accesible por red desde cada producto protegido de Lerian.

### Servicio Identity

El lado de datos de Access Manager: usuarios, grupos, aplicaciones, proveedores de comunicación, vínculos entre aplicaciones y proveedores, y configuración de MFA. Identity es la superficie de gestión. Tanto Identity como Auth se conectan al backend Casdoor configurado: Identity gestiona los datos de identidad a través de él, mientras que Auth usa su propia conexión para tokens, MFA y decisiones de autorización.

### Backend de identidad

Access Manager usa un backend Casdoor configurado para el almacenamiento de identidad. Casdoor persiste sus datos de identidad en la base de datos PostgreSQL configurada; PostgreSQL respalda a Casdoor, no lo reemplaza. En SaaS y en la mayoría de los despliegues BYOC, el backend viene preconfigurado. Para un despliegue BYOC, configura ese backend Casdoor para tu entorno; Access Manager no se conecta directamente a APIs arbitrarias de proveedores de identidad.

### Servicios de datos y caché

* Una instancia de **PostgreSQL** como base de datos de respaldo para los datos de identidad gestionados por Casdoor.
* Una caché **Valkey** para operaciones relacionadas con tokens, permisos y MFA.

Ambas deben estar aprovisionadas y accesibles antes de que Auth e Identity inicien. Las decisiones de dimensionamiento y alta disponibilidad dependen de tu modelo de despliegue.

### Conectividad de productos

Planifica las rutas de red ahora para no tener que depurarlas después:

* Los productos protegidos deben alcanzar **Auth** por red.
* Los administradores (y cualquier herramienta de back-office) deben alcanzar **Identity** para gestionar usuarios, grupos, aplicaciones y proveedores.
* Ninguno de los dos servicios debe exponerse públicamente sin los controles de ingress adecuados.

### Datos de entorno y bootstrap

Un entorno single-tenant nuevo siembra una vez al iniciar sus datos de acceso base, incluidos organización, roles integrados, grupos, aplicaciones y conjuntos de permisos. El bootstrap multi-tenant prepara solo material de certificado compartido; las organizaciones y los datos de acceso de tenant se crean después de que exista el tenant. Esta es la capa de **bootstrap**. Una vez que el entorno está en funcionamiento, los cambios del día a día se realizan a través de las APIs de Identity o de Lerian Console, no editando datos de bootstrap.

<Warning>
  Los datos sembrados por bootstrap solo se aplican 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 reconciliador idempotente.
</Warning>

## Flujo de instalación

***

Sigue estos pasos en orden. Cada uno se apoya en el anterior, y saltarse pasos es la causa más común de problemas evitables más adelante.

<Steps>
  <Step title="Elige tu modelo de despliegue">
    Elige SaaS, BYOC multi-tenant o BYOC single-tenant y confirma cualquier decisión específica del modelo con tu contacto de Lerian: estrategia de tenant, configuración de Casdoor y alcance de la licencia. Anótalo, porque cada paso posterior se refiere a esta elección.
  </Step>

  <Step title="Prepara las dependencias">
    Aprovisiona la infraestructura de soporte para que Auth e Identity tengan todo lo que necesitan al iniciar:

    * una licencia válida de Lerian configurada para el entorno;
    * una instancia de PostgreSQL para respaldar los datos de identidad gestionados por Casdoor;
    * una caché Valkey para tokens, permisos y MFA;
    * el backend de identidad Casdoor configurado;
    * las rutas de red entre Access Manager, sus dependencias y los productos que eventualmente aplicarán el control de acceso.

    No avances hasta que cada dependencia sea accesible desde donde se ejecutará Access Manager.
  </Step>

  <Step title="Despliega Auth e Identity">
    Instala los servicios de Access Manager en tu entorno. Para Kubernetes, la ruta soportada es el Helm chart. Consulta [Access Manager con Helm](/es/platform/helm/access-manager/access-manager-helm) para las versiones del chart, el registro OCI y el comando `helm install` exacto.

    Si solo necesitas evaluar Access Manager localmente antes de un despliegue real, usa el comando `make up` del repositorio fuente. Construye e inicia el stack de Access Manager. Usa los comandos de ciclo de vida documentados por la revisión del repositorio que ejecutas.
  </Step>

  <Step title="Realiza el bootstrap de los datos de acceso base">
    En modo single-tenant, el primer inicio siembra la organización base, los roles integrados, grupos, aplicaciones y conjuntos de permisos de los que depende la plataforma. En modo multi-tenant, el bootstrap no siembra organizaciones ni datos de acceso de tenant; crea esos datos después de crear el tenant. Deja que el bootstrap termine antes de apuntar cualquier producto a los servicios.

    A partir de este punto, trata los datos de bootstrap como de solo lectura. Gestiona el acceso del día a día a través de las APIs de Identity o de Lerian Console.
  </Step>

  <Step title="Valida los servicios">
    Confirma que la instalación esté saludable *antes* de que cualquier producto dependa de ella:

    * Auth e Identity reportan estar saludables y son accesibles desde los productos que los usarán.
    * PostgreSQL (la base de datos de respaldo de Casdoor) y Valkey están conectados y responden.
    * El backend de identidad Casdoor está configurado y es accesible.
    * Una solicitud de token de prueba contra Auth tiene éxito, y una llamada básica a Identity (por ejemplo, [Listar grupos](/es/reference/access-manager/list-groups)) funciona para el modelo de despliegue elegido. En modo multi-tenant, crea datos de acceso de tenant antes de esperar que devuelva grupos.

    Si algo de esta lista falla, corrígelo aquí. No habilites productos sobre una instalación que no esté saludable.
  </Step>

  <Step title="Habilita los productos protegidos">
    Una vez validada la instalación, activa el control de acceso dentro de cada producto o plugin de Lerian configurando las variables de Auth en su `.env`. La configuración completa por producto, incluidos los ajustes multi-tenant, está en [Habilitar Access Manager](/es/platform/access-manager/enabling-access-manager).
  </Step>

  <Step title="Usa Access Manager">
    Con la instalación lista y los productos aplicando el control de acceso, pasa a la operación del día a día: solicitar tokens, gestionar usuarios, grupos y aplicaciones, configurar MFA y llamar a APIs protegidas. Empieza con [Usar Access Manager](/es/platform/access-manager/using-access-manager) para el flujo por API, o con [Access Manager con Lerian Console](/es/platform/access-manager/using-access-manager-with-midaz-console) para el flujo visual.
  </Step>
</Steps>

<Tip>
  Trata la instalación como un hito propio. Auth e Identity deben estar desplegados, saludables y validados *antes* de poner cualquier producto en modo de control de acceso. Ese único hábito evita la mayoría de los incidentes del primer día.
</Tip>

## Próximos pasos

***

* [Habilitar Access Manager](/es/platform/access-manager/enabling-access-manager) - activa el control de acceso en cada producto de Lerian.
* [Usar Access Manager](/es/platform/access-manager/using-access-manager) - solicita tokens, gestiona usuarios y aplicaciones, configura MFA.
* [Access Manager con Helm](/es/platform/helm/access-manager/access-manager-helm) - versiones del chart, registro OCI y comandos de instalación.
* [Cómo funciona Access Manager](/es/platform/access-manager/am-components) - una mirada más cercana a Auth, Identity y el control de acceso a nivel de producto.