Skip to main content
Instalar o Access Manager não basta por si só. Para começar a aplicar o controle de acesso, você o ativa em cada produto definindo as variáveis de Auth no arquivo .env de qualquer produto ou plugin da Lerian onde quiser deixá-lo ativo.
Habilitar o Access Manager apenas liga a aplicação de autorização em um produto ou plugin. Dados de acesso como usuários, grupos, aplicações, providers, roles e permissões são gerenciados separadamente através do Access Manager.
Cada produto protegido precisa habilitar a validação e apontar para o Auth. A variável de endereço não é a mesma em todos os repositórios, então use a variável esperada pelo produto que você está configurando:
Para um produto que suporta multi-tenancy BYOC, configure o conjunto completo de variáveis específico do produto. Para o Midaz Ledger, habilitar multi-tenancy também exige a URL do seu serviço Tenant Manager e um host do Valkey. O Tenant Manager escuta na porta 4026 por padrão:
Aponte MULTI_TENANT_URL para um endpoint HTTPS para que MULTI_TENANT_SERVICE_API_KEY não trafegue por HTTP em texto claro. O HTTP dentro do cluster (http://tenant-manager.<namespace>.svc.cluster.local:4026) é somente para clusters locais e não produtivos e exige o opt-in explícito MULTI_TENANT_ALLOW_INSECURE_HTTP=true. Em deployments Helm, o Midaz também exige MULTI_TENANT_SERVICE_API_KEY, normalmente fornecida por um Secret ou Secret existente. A flag sozinha não completa a configuração multi-tenant; siga a documentação de deploy do produto que você está configurando. Se SERVER_ADDRESS ou o Service do Tenant Manager substituir a porta padrão, use esse endereço implantado.
Uma vez que o Access Manager esteja habilitado, as requisições a APIs protegidas devem incluir um header Authorization com um Bearer access token válido.Sem esse header, requisições protegidas serão rejeitadas, mesmo para endpoints que antes eram acessíveis sem autenticação.Aprenda como gerar e usar access tokens.

​
Onde atualizar

Você encontrará os arquivos .env relevantes nestas localizações:
  • Midaz
    • /midaz/components/ledger usa PLUGIN_AUTH_HOST. O componente CRM usa PLUGIN_AUTH_ADDRESS em sua própria configuração.
    • /midaz/components/tracer usa PLUGIN_AUTH_ADDRESS
  • Outros produtos e plugins
    • Use o arquivo .env na raiz do produto ou plugin, ou no diretório do componente quando o repositório for dividido em componentes.
    • Reporter, Flowker, Bank Transfer e Fetcher usam PLUGIN_AUTH_ADDRESS.
    • Pix Indirect BTG usa PLUGIN_AUTH_ADDRESS no serviço pix e PLUGIN_AUTH_HOST nos workers inbound e outbound.
    • Pix Direct JD usa PLUGIN_AUTH_HOST.
Não consegue ver os arquivos? Ajuste as configurações do seu sistema para mostrar arquivos ocultos. Arquivos .env geralmente ficam ocultos por padrão.

​
Reconstruir após as alterações

Após atualizar um arquivo .env, reconstrua e reinicie a partir da raiz do repositório que contém esse arquivo. Os comandos de ciclo de vida variam por repositório: na raiz do repositório do Midaz, execute make rebuild-up, porque o alvo make up dele inicia os serviços sem reconstruí-los. Para outros produtos e plugins, use o comando de ciclo de vida documentado naquele repositório. O código-fonte do Access Manager usa os comandos a seguir:
1
No seu terminal, vá para a raiz do repositório do Access Manager.
2
Se o Docker estiver rodando, pare-o:
3
Então construa e inicie a stack:

​
Ciclo de vida do deployment

A configuração do Access Manager tem duas fases, e o bootstrap varia conforme o modelo de deployment:
  • Bootstrap single-tenant popula um novo ambiente com a organização, roles, groups, aplicações e permission sets básicos exigidos pela plataforma.
  • Bootstrap multi-tenant prepara apenas o material de certificado compartilhado. Ele não popula organizações, usuários, groups, aplicações ou permission sets de tenant; crie e gerencie os dados de acesso do tenant depois que ele existir.
  • Operação começa quando o ambiente está em execução. A partir daí, gerencie o acesso pelas APIs do Identity ou pelo Lerian Console.
Use as APIs operacionais para acesso de usuários, atribuição de grupos, credenciais de aplicação, providers e MFA. Não altere um ambiente em execução editando arquivos de seed do bootstrap.
Os dados de seed do bootstrap são aplicados apenas durante a configuração inicial do ambiente. Mudanças em resources, actions, roles, groups, aplicações ou permission sets nativos em um ambiente existente devem ser entregues por atualizações controladas da plataforma, como migrations ou um reconciler idempotente.