Depuração do Credentials Proxy do Orchestrator

Logs

Por padrão, o Orchestrator Credentials Proxy registra todas as exceções e as informações de inicialização e desligamento.

Para verificar se o Credentials Proxy está realmente registrando 200 solicitações, inicie o Orchestrator Credentials Proxy no servidor local, acesse o Swagger e execute o endpoint de Saúde (não autenticado): api/v1/Health. As solicitações devem ser registradas agora.

Observação: após cada alteração no arquivo appsettings , você precisa reiniciar o proxy de credenciais.

Se você seguir essas etapas e nenhum log adicional além de inicialização e desligamento estiver disponível, isso significa que nenhuma solicitação está chegando ao Credentials Proxy do Orchestrator. Isso é provavelmente causado por um problema de infraestrutura ou rede nas máquinas do Orchestrator Cloud Robot e das máquinas do Orchestrator Credentials Proxy.

Visualizador de eventos

Todos os logs devem aparecer no Visualizador de Eventos do Windows para o Orchestrator Credentials Proxy versões 2.0.0 e superiores.

Alteração do destino do arquivo de log

Para alterar o caminho do arquivo de log, abra o arquivo appsettings.production.json e use o seguinte código. Você pode substituir C:/dev/logs pelo caminho desejado:

"NLog": {
    "throwConfigExceptions": true,
    "targets": {
      "logfile": {
        "type": "File",
        "maxArchiveFiles": 180,
        "fileName": "C:/dev/logs/nlog-${shortdate}.log",
        "layout": "${longdate} ${logger} ${message}${onexception:${newline}${exception:maxInnerExceptionLevel=10:format=shortType,message,stacktrace:separator=*:innerExceptionSeparator=
	}}"
      }
    },
    "rules": [
      {
        "logger": "*",
        "minLevel": "Information",
        "writeTo": "logconsole,logfile,eventLog"
      }
    ]
  }

Logs adicionais

Observação: esse procedimento deve ser usado apenas para depuração. Quando terminar, reverta essas alterações, pois isso produzirá logs excessivos.

Os níveis de log padrão são semelhantes aos seguintes:

"Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },

Se você quiser obter mais logs, por exemplo, para ver todas as solicitações vindas do proxy, você precisa editar o arquivo appsettings.Production.json e adicionar o seguinte:

"Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Information",
      "Microsoft.AspNetCore": "Information",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
    }
  }

Se o Information não for suficiente e você quiser mais ou menos, você pode usar os valores LogLevels do .Net. Para obter mais informações, consulte a documentação da Microsoft. O arquivo appsettings.json deve ter aparência semelhante ao seguinte:

"Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Information",
      "Microsoft.AspNetCore": "Information",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
    }
  }

Reinicie o Credentials Proxy do Orchestrator após alterar o arquivo appsettings .

Testar com InMemory Store

Se você estiver tendo problemas para depurar e quiser verificar com um tipo de armazenamento de credenciais diferente, você pode usar o tipo InMemorySecureStore de Credentials Proxy do Orchestrator.

Observação: use esse procedimento apenas para fins de teste.

Para habilitar o tipo InMemorySecureStore , abra o arquivo appsettings.production.json , vá para a seção AppSettings e adicione o parâmetro "UseInMemorySecureStore": "true" .

Para habilitá-lo para proxies desconectados , inclua também o seguinte na seção SecureStoreConfigurations :

{
  "Key": "InMemoryKey1", // can be any value
  "Type": "InMemorySecureStore",
  "Context": {
  }
}

Não foi possível conectar o proxy conectado

Ao configurar uma conexão do Orchestrator Credentials Proxy e tentar vinculá-la ao Orchestrator, você pode encontrar a seguinte mensagem de erro:

Request to the Credentials Proxy's unauthenticated health endpoint failed.

Durante o processo de conexão, o Orchestrator executa uma solicitação GET simples para o ponto de extremidade do proxy /api/v1/Health .

O objetivo desta solicitação é verificar se o proxy pode ser acessado a partir do ambiente de nuvem do Orchestrator. Se essa solicitação falhar, isso indica que o Orchestrator não pode acessar o proxy e a verificação de conexão não será aprovada.

Problemas comuns

• O Orchestrator Credentials Proxy não foi iniciado:

  • Acesse o servidor em que o Credentials Proxy do Orchestrator está instalado.

  • No IIS, verifique se o aplicativo de proxy de credenciais está em execução.

  • No mesmo servidor, abra um navegador e verifique se a URL do Credentials Proxy está acessível localmente.

• A conexão não tem um certificado HTTPS/SSL válido. Toda a comunicação entre o Orchestrator e o OCP deve ser protegida.

  • Certifique-se de que seu proxy de credenciais use um certificado HTTPS/SSL válido.

  • (Opcional) Se um balanceador de carga estiver configurado em frente ao Orchestrator Credentials Proxy, confirme se ele também usa uma conexão HTTPS segura.

• O Orchestrator Credentials Proxy está bloqueado atrás de um firewall, VPN ou restrição de rede semelhante. Se o proxy de credenciais não for acessível a partir do Orchestrator, verifique a configuração de sua rede.
  • Certifique-se de que os IPs de saída do Orchestrator estejam devidamente na lista de permissões. Verifique a página Endereços IP de saída do Orchestrator para obter mais informações.
    Nota: Se sua organização tiver vários tenants, eles podem ser hospedados em diferentes regiões e usar diferentes endereços IP. Verifique duas vezes para cada tenant.
• Problema de ponto de extremidade não autenticado devido a horário incorreto do servidor.
  • Se o ponto de extremidade não autenticado falhar, é possível que o horário do servidor não esteja definido corretamente. Quando o horário do sistema não é preciso, o servidor pode interpretar tokens JWT como inválidos.

Etapas a serem investigadas

1. Verifique no IIS se o Orchestrator Credentials Proxy está em execução.
2. Verifique no navegador se a URL do Credentials Proxy está acessível e se carrega corretamente.
3. Verifique no navegador se o URL do Credentials Proxy está seguro.
4. Na máquina do proxy de credenciais, aumente o nível de log para Informações para solução de problemas. lembre-se de reverter essa alteração após concluir a investigação.
5. Teste o ponto de extremidade de integridade localmente. Na máquina de proxy de credenciais, abra o Swagger ou use uma ferramenta como o Postman para fazer uma solicitação para:

   https://{yourCredentialsProxyUrl}/api/v1/Health

   Uma resposta bem-sucedida indica que o proxy é acessível e está operacional localmente.

6. Teste o acesso dentro da VPN. De outra máquina dentro da mesma VPN (por exemplo, o laptop de um cliente ou a máquina do robô de um cliente), verifique se o URL do Credentials Proxy está acessível. Faça uma solicitação para o mesmo endpoint /api/v1/Health :

   • Se funcionar, o Credentials Proxy será acessível de dentro da VPN.

   • Se isso não acontecer, o cliente deve resolver o problema interno da rede ou roteamento.

7. Teste a acessibilidade pública.
8. Em uma máquina que não esteja dentro da VPN, verifique o ponto de extremidade /api/v1/Health :

   • Se funcionar, o Credentials Proxy será acessível de fora da VPN.

   • Se isso não acontecer, o cliente deve resolver o problema interno da rede ou roteamento.

9. Teste a conexão do Cloud Orchestrator. Crie um novo Credentials Proxy vinculado ao mesmo URL do proxy:

   • Se a criação for bem-sucedida, você poderá excluir a conexão.

   • Se ela falhar, algo ainda estará bloqueando a comunicação entre o Orchestrator e o Credentials Proxy.

     Observação: neste momento, o proxy de credenciais deve estar acessível publicamente, sem restrições de firewall ou lista de permissão de IP.
10. Recupere a lista de endereços IP de tenant do Orchestrator.

11. Adicione os IPs à lista de permissões para acessar o Credentials Proxy.

12. Em uma máquina fora da VPN, teste o ponto de extremidade /api/v1/Health novamente. Não deve funcionar, pois o IP não é adicionado à lista de permissões.
13. No Orchestrator Cloud, tente criar um proxy de credenciais novamente:
    • Se todas as etapas tiverem sido concluídas corretamente, a automação deve ser bem-sucedida.
    • Se ainda falhar, pode haver um problema com o firewall ou as regras da VPN que impedem a comunicação entre o Orchestrator e o Credentials Proxy.
14. Se o problema persistir, repita as etapas acima cuidadosamente e verifique cada ponto de configuração.
15. Depois que o problema for resolvido, reverta o nível de log na máquina do Credentials Proxy para sua configuração original.

O proxy desconectado não será iniciado ou registrado

O proxy de credenciais desconectadas realiza uma etapa de validação durante a inicialização para garantir que possa atender corretamente às solicitações dos clientes. Como parte desse processo, o proxy valida cada configuração definida em AppSettings:SecureStoreConfigurations. A lógica de validação específica aplicada depende do tipo de armazenamento de credenciais configurado.

Em certos casos, a causa raiz da falha ao iniciar o proxy pode ocorrer tão cedo no processo de inicialização que o aplicativo não atinge o ponto de gerar ou gravar quaisquer eventos de log.

Possíveis motivos para o aplicativo não iniciar

Vários problemas podem impedir que o aplicativo Credentials Proxy seja iniciado. Veja abaixo causas comuns e como identificá-las.

• Pool de aplicativos IIS não iniciado (Windows). Se o proxy estiver hospedado no IIS, verifique se o pool de aplicativos associado a ele está em execução. Você pode verificar isso no Gerenciador do IIS na seção Pools de aplicativos .
• Configuração inválida em appsettings.Production.json. Um arquivo de configuração inválido ou incompleto pode fazer com que o proxy falhe durante a inicialização. Verifique os exemplos na seção Amostras de configuração para obter mais detalhes.
• Configuração inválida em AppSettings:SecureStoreConfigurations. A seção SecureStoreConfigurations define como o proxy se conecta e valida os armazenamentos de credenciais. Se alguma dessas entradas estiver malformada ou incompleta, o aplicativo não será iniciado.
  • Parâmetros inválidos na configuração. Certifique-se de que todos os parâmetros de configuração correspondam ao tipo de armazenamento de credenciais que você está usando. O uso de parâmetros ou chaves incorretos pode causar uma falha na validação de inicialização.
  • Não foi possível acessar o cofre. Se o armazenamento de credenciais configurado depender de um cofre externo (por exemplo, CyberArk, BeyondTrust ou outros), a inicialização pode falhar se o proxy não puder alcançar ou autenticar com ele.
• Outros problemas relacionados à infraestrutura.

Depuração

Ao depurar o Credentials Proxy, o objetivo é eliminar o maior número possível de variáveis antes de testar configurações complexas.

• Comece usando uma configuração mínima com o tipo InMemorySecureStore . Isso permite que você confirme que o proxy pode ser iniciado com sucesso antes de introduzir dependências externas.
  • Adicione o parâmetro "UseInMemorySecureStore": "true", em AppSettings.
  • Adicione o seguinte em AppSettings:SecureStoreConfigurations:

    "SecureStoreConfigurations": [
      {
        "Key": "InMemoryKey1",
        "Type": "InMemorySecureStore",
        "Context": {  }
      }
    ]

  • O proxy não deve mais ter problemas relacionados à configuração. Se ainda falhar ao iniciar, a causa provavelmente está relacionada à infraestrutura.
• Depois de confirmar que o proxy começa com sucesso a usar a configuração na memória, substitua-a por sua configuração de armazenamento de credenciais real (por exemplo, CyberArk, BeyondTrust e outros).
  • Atualize a seção SecureStoreConfigurations com base em seu ambiente e tipo de armazenamento.

    Se o aplicativo falhar ao iniciar, você deve encontrar logs em:

    • O Visualizador de eventos do Windows.

    • O diretório de logs configurado do proxy.

  • Se o aplicativo não iniciar e nenhum log for gerado, o problema provavelmente está relacionado à infraestrutura ou permissões em seu ambiente.

    Para ajudar na depuração nesses casos, você pode desabilitar temporariamente a validação de armazenamento seguro adicionando esse parâmetro em AppSettings:

    "SkipValidateSecureStoreConfigurations": true

    Observação: Esse parâmetro deve ser usado apenas para fins de depuração. A validação de inicialização existe para garantir que sua configuração de proxy esteja correta e segura.