Depuración de Credentials Proxy de Orchestrator

Registros

De forma predeterminada, el Credentials Proxy de Orchestrator registra todas las excepciones y la información de inicio y apagado.

Para comprobar si Credentials Proxy está realmente registrando 200 solicitudes, inicia Credentials Proxy de Orchestrator en el servidor local, ve a Swagger y ejecuta el punto final sanitario (no autenticado): api/v1/Health.Ahora las solicitudes deben registrarse.

Nota: Tienes que reiniciar Credentials Proxy cada vez que cambies el archivo appsettings.

Si sigues estos pasos y solo ves los registros inicio y apagado, las solicitudes no llegan al Credentials Proxy de Orchestrator.Lo más probable es que esto lo cause una incidencia de infraestructura o de red de las máquinas de Orchestrator Cloud Robot y Credentials Proxy de Orchestrator.

Visor de eventos

Todos los registros deben aparecer en el visor de eventos de Windows para Credentials Proxy de Orchestrator versiones 2.0.0 y superiores.

Cambiar el destino del archivo de registro

Para cambiar la ruta del archivo de registro, abre el archivo appsettings.production.json y utiliza el siguiente código. Puedes reemplazar C:/dev/logs por la ruta que quieras:

  "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"
      }
    ]
  }

Registros adicionales

Nota: Este procedimiento solo debe utilizarse para depurar. Cuando lo hagas, revierte estos cambios, ya que producirá demasiados registros.

Los niveles de registro predeterminados se parecen a los siguientes:

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

Si quieres obtener más registros, por ejemplo, para ver todas las solicitudes que se envían al proxy, debes editar el appsettings.Production.json archivo y añadir lo siguiente:

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

Si el Information no es suficiente y quieres más o menos, puedes utilizar los valores LogLevels de .Net. Para más información, consulta la documentación de Microsoft. El archivo appsettings.json debe tener un aspecto similar al siguiente:

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

Reinicia el Credentials Proxy de Orchestrator después de cambiar el archivo appsettings.

Prueba con InMemoryStore

Si tienes incidencias de depuración y quieres probar con un tipo de almacén de credenciales diferente, puedes utilizar el tipo InMemorySecureStore de Credentials Proxy de Orchestrator.

Nota: Usa este procedimiento solo con fines de prueba.

Para habilitar el InMemorySecureStore tipo, abre el appsettings.production.json archivo, ve a la sección AppSettingsy añade el "UseInMemorySecureStore": "true" parámetro.

Para habilitarla para los proxies desconectados, incluye también lo siguiente en la SecureStoreConfigurationssección:

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

El proxy conectado no se pudo conectar

Cuando se configura una conexión de Credentials Proxy de Orchestrator e intentas vincularla a Orchestrator, es posible que aparezca el siguiente mensaje de error:

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

Durante el proceso de conexión, Orchestrator realiza una solicitud GET simple al punto /api/v1/Health final del proxy.

El propósito de esta solicitud es verificar que se pueda acceder al proxy desde el entorno de nube de Orchestrator. Si esta solicitud falla, indica que Orchestrator no puede acceder al proxy y que la comprobación de la conexión fallará.

Problemas comunes

• El Credentials Proxy de Orchestrator no se inicia:

  • Ve al servidor en el que está instalado el Credentials Proxy de Orchestrator.

  • En IIS, verifica que la aplicación Credentials Proxy se esté ejecutando.

  • En el mismo servidor, abre un explorador y comprueba que puedas acceder de forma local a la URL de Credentials Proxy.

• La conexión no tiene un certificado HTTPS/SSL válido. Todas las comunicaciones entre Orchestrator y OCP deben ser seguras.

  • Asegúrate de que tu Credentials Proxy utilice un certificado HTTPS/SSL válido.

  • (Opcional) Si se configura un equilibrador de carga delante del Credentials Proxy de Orchestrator, confirma que también utiliza una conexión HTTPS segura.

• El Credentials Proxy de Orchestrator está bloqueado detrás de un cortafuegos, VPN o restricción de red similar. Si no se puede acceder al Credentials Proxy desde Orchestrator, verifica la configuración de tu red.
  • Asegúrate de que las IP salientes de Orchestrator estén correctamente en la lista blanca. Para obtener más información, consulta la página Direcciones IP salientes de Orchestrator.
    Nota: Si tu organización tiene varios tenants, es posible que estén alojados en diferentes regiones y que utilicen diferentes direcciones IP. Compruébalo para cada tenant.
• Incidencia de punto final no autenticado debido a que la hora del servidor es incorrecta.
  • Si el punto final no autenticado falla, es posible que la hora del servidor no sea la correcta. Cuando el reloj del sistema es inexacto, el servidor puede interpretar los tokens JWT como no válidos.

Pasos para investigar

1. Verifica en el IIS que se esté ejecutando el Credentials Proxy de Orchestrator.
2. Comprueba en el explorador que la URL del Credentials Proxy sea accesible y se cargue correctamente.
3. Comprueba en el explorador que la URL del Credentials Proxy sea segura.
4. En la máquina Credentials Proxy, aumenta el nivel de registro a Information para la solución de problemas. Acuérdate de revertir este cambio cuando acabes de investigar.
5. Prueba localmente el punto de conexión sanitario. En la máquina de Credentials Proxy, abre Swagger o utiliza una herramienta como Postman para hacer una solicitud a:

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

   Una respuesta correcta indica que el proxy es accesible y está operativo localmente.

6. Prueba el acceso dentro de la VPN. Desde otra máquina de la misma VPN (por ejemplo, el portátil de un cliente o la máquina del robot de un cliente), comprueba que se pueda acceder a la URL de Credentials Proxy. Haz una solicitud al mismo punto final /api/v1/Health:

   • Si funciona, se puede acceder al Credentials Proxy desde dentro de la VPN.

   • Si no es así, el cliente debe resolver la incidencia de la red interna o del enrutamiento.

7. Prueba la accesibilidad pública.
8. En una máquina que no esté dentro de la VPN, comprueba el punto final /api/v1/Health:

   • Si funciona, se puede acceder al Credentials Proxy desde fuera de la VPN.

   • Si no es así, el cliente debe resolver la incidencia de la red interna o del enrutamiento.

9. Prueba la conexión desde la nube de Orchestrator. Crea un nuevo Credentials Proxy que esté vinculado a la misma URL del proxy:

   • Si la creación se realiza correctamente, puedes eliminar la conexión.

   • Si falla, algo sigue bloqueando la comunicación entre Orchestrator y el Credentials Proxy.

     Nota: En este punto, el Credentials Proxy debe ser accesible públicamente, sin restricciones de firewall ni listas blancas de IP.
10. Recupera la lista de direcciones IP de tenants de Orchestrator.

11. Añade las IP a la lista de permitidas para acceder al Credentials Proxy.

12. Desde una máquina que esté fuera de la VPN, vuelve a probar el punto final /api/v1/Health. No debería funcionar, ya que la IP no se añade a la lista de permisos.
13. En Orchestrator Cloud, vuelve a intentar crear un Credentials Proxy:
    • Si todos los pasos se han completado correctamente, ahora debería tener éxito.
    • Si sigue fallando, es posible que haya una incidencia con las reglas del cortafuegos o de la VPN que impiden que Orchestrator y Credentials Proxy se comuniquen entre sí.
14. Si la incidencia persiste, repite los pasos anteriores cuidadosamente y verifica cada punto de configuración.
15. Cuando resuelvas la incidencia, devuelve el nivel de registro de la máquina de Credentials Proxy a su configuración original.

El proxy desconectado no se iniciará ni registrará

El Credentials Proxy desconectado realiza un paso de validación durante el inicio para garantizar que pueda servir correctamente a las solicitudes del cliente. Como parte de este proceso, el proxy valida cada configuración definida en AppSettings:SecureStoreConfigurations. La lógica de validación específica que se aplica depende del tipo de almacén de credenciales configurado.

En algunos casos, la causa raíz del fallo del proxy puede ocurrir tan temprano en el proceso de inicio que la aplicación no llega a generar o escribir ningún evento de registro.

Posibles causas por las que la aplicación no se inicia

Varias incidencias pueden evitar que se inicie la aplicación Credentials Proxy. A continuación se muestran las causas comunes y cómo identificarlas.

• Grupo de aplicaciones IIS no iniciado (Windows). Si el proxy está alojado en IIS, verifica que el grupo de aplicaciones asociado a él se esté ejecutando. Puedes comprobarlo en el Gestor de IIS en la sección Grupos de aplicaciones.
• Configuración no válida en appsettings.Production.json. El proxy puede fallar durante el inicio si el archivo de configuración no es válido o está incompleto. Para obtener más detalles, consulta los ejemplos de la sección Ejemplos de configuración.
• Configuración no válida en AppSettings:SecureStoreConfigurations. La sección SecureStoreConfigurations define cómo el proxy se conecta a los almacenes de credenciales y los valida. Si alguna de estas entradas está mal formada o está incompleta, la aplicación no se iniciará.
  • Parámetros no válidos en la configuración. Asegúrate de que todos los parámetros de configuración coincidan con el tipo de almacén de credenciales que utilizas. El uso de parámetros o claves incorrectos puede provocar que la validación de inicio falle.
  • No se puede acceder al almacén. El inicio puede fallar si el almacén de credenciales configurado depende de un almacén externo (por ejemplo, CyberArk, BeyondTrust u otros) y el proxy no puede acceder a él o autenticarse con él.
• Otras incidencias relacionadas con la infraestructura.

Depuración

El objetivo de depurar el proxy de credenciales es eliminar el mayor número de variables posible antes de probar configuraciones complejas.

• Comienza utilizando una configuración mínima con el tipo InMemorySecureStore. Esto te permite confirmar que el proxy puede iniciarse correctamente antes de introducir dependencias externas.
  • Añade el "UseInMemorySecureStore": "true", parámetro en AppSettings.
  • Añade lo siguiente en AppSettings:SecureStoreConfigurations:

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

  • El proxy ya no debe tener incidencias relacionadas con la configuración. Si sigue sin iniciarse, lo más probable es que la causa esté relacionada con la infraestructura.
• Cuando hayas confirmado que el proxy se inicia correctamente con la configuración en memoria, reemplázalo con la configuración del almacén de credenciales real (por ejemplo, CyberArk, BeyondTrust y otros).
  • Actualiza la sección SecureStoreConfigurations en función de tu entorno y tipo de almacén.

    Si la aplicación no se inicia, busca los registros en:

    • El visor de eventos de Windows.

    • El directorio de registros configurados del proxy.

  • Si la aplicación no se inicia y no se generan registros, es probable que la incidencia esté relacionada con la infraestructura o los permisos de tu entorno.

    Para ayudar a depurar en esos casos, puedes añadir este parámetro a AppSettings para deshabilitar temporalmente la validación del almacén seguro:

    "SkipValidateSecureStoreConfigurations": true
    

    Nota: Este parámetro solo se debe utilizar con fines de depuración. La validación de inicio se ha creado para que te asegures que la configuración de tu proxy sea correcta y segura.