Depuración de Credentials Proxy de Orchestrator

Registros

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

Para comprobar si el proxy de credenciales realmente está registrando 200 solicitudes, inicia el Credentials Proxy de Orchestrator en el servidor local, ve a Swagger y ejecuta el punto final de Salud (no autenticado): api/v1/Health. Las solicitudes deberían registrarse ahora.

Nota: después de cada cambio en el archivo appsettings , debes reiniciar el proxy de credenciales.

Si sigues estos pasos y no hay registros adicionales disponibles además del inicio y el apagado, eso significa que no llega ninguna solicitud al Credentials Proxy de Orchestrator. Lo más probable es que esto se deba a un problema de infraestructura o de red en las máquinas de Orchestrator Cloud Robot y Orchestrator Credentials Proxy.

Visor de eventos

Todos los registros deben aparecer en el Visor de eventos de Windows para las versiones 2.0.0 y posteriores de Orchestrator Credentials Proxy.

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 deseada:

"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 la depuración. Cuando haya terminado, revierta estos cambios, ya que producirá registros excesivos.

Los niveles de registro predeterminados son similares a los siguientes:

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

Si quieres obtener más registros, por ejemplo para ver todas las solicitudes que llegan al proxy, debes editar el archivo appsettings.Production.json 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 obtener más información, consulta la documentación de Microsoft. El archivo appsettings.json debería ser 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 problemas con la depuración y quieres comprobar con un tipo de almacén de credenciales diferente, puedes utilizar el tipo InMemorySecureStore de Credentials Proxy de Orchestrator.

Nota: utiliza este procedimiento solo con fines de prueba.

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

Para habilitarlo para proxies desconectados , incluye también lo siguiente en la sección SecureStoreConfigurations :

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

El proxy conectado no pudo conectarse

Al configurar una conexión de Credentials Proxy de Orchestrator e intentar vincularla con Orchestrator, puede aparecer 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 final del proxy /api/v1/Health .

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

Problemas comunes

• El Credentials Proxy de Orchestrator no se ha iniciado:

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

  • En IIS, comprueba que la aplicación de proxy de credenciales se está ejecutando.

  • En el mismo servidor, abre un navegador y comprueba que la URL del proxy de credenciales es accesible localmente.

• La conexión no tiene un certificado HTTPS/SSL válido. Toda la comunicación entre Orchestrator y OCP debe ser segura.

  • Asegúrate de que tu proxy de credenciales utiliza 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 tras un cortafuegos, una VPN o una restricción de red similar. Si no se puede acceder al proxy de credenciales desde Orchestrator, verifica tu configuración de red.
  • Asegúrate de que las IP salientes de Orchestrator están correctamente en la lista de confianza. Consulta la página Direcciones IP salientes de Orchestrator para obtener más información.
    Nota: si tu organización tiene varios tenants, es posible que estén alojados en diferentes regiones y utilicen diferentes direcciones IP. Vuelve a comprobar para cada tenant.
• Problema de punto final no autenticado debido a una hora incorrecta del servidor.
  • Si el punto final no autenticado falla, es posible que la hora del servidor no esté configurada correctamente. 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 el Credentials Proxy de Orchestrator se está ejecutando.
2. Comprueba en el navegador que la URL del proxy de credenciales es accesible y se carga correctamente.
3. Comprueba en el navegador que la URL del proxy de credenciales es segura.
4. En la máquina del proxy de credenciales, aumenta el nivel de registro a Información para la resolución de problemas. Recuerde revertir este cambio después de completar la investigación.
5. Prueba el punto final de salud localmente. En la máquina del proxy de credenciales, abre Swagger o utiliza una herramienta como Postman para realizar una solicitud para:

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

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

6. Pruebe el acceso dentro de la VPN. Desde otra máquina dentro de la misma VPN (por ejemplo, el portátil de un cliente o la máquina robot de un cliente), comprueba que la URL del proxy de credenciales es accesible. Haz una solicitud al mismo punto final /api/v1/Health :

   • Si funciona, se puede acceder al proxy de credenciales desde dentro de la VPN.

   • Si no es así, el cliente debe resolver la red interna o el problema de 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 proxy de credenciales desde fuera de la VPN.

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

9. Prueba la conexión desde la nube de Orchestrator. Crea un nuevo proxy de credenciales vinculado a la misma URL de 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 proxy de credenciales.

     Nota: En este punto, el proxy de credenciales debe ser accesible públicamente, sin restricciones de firewall o listas de confianza de IP.
10. Recupera la lista de direcciones IP de tenant de Orchestrator.

11. Añade las IP a la lista de permisos para acceder al proxy de credenciales.

12. Desde una máquina 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, intenta crear un proxy de credenciales de nuevo:
    • Si todos los pasos se han completado correctamente, ahora debería tener éxito.
    • Si aún falla, puede haber un problema con el firewall o las reglas de VPN que impiden la comunicación entre Orchestrator y el proxy de credenciales.
14. Si el problema persiste, repite los pasos anteriores cuidadosamente y verifica cada punto de configuración.
15. Una vez resuelto el problema, revierte el nivel de registro en la máquina del proxy de credenciales a su configuración original.

El proxy desconectado no se iniciará ni registrará

El proxy de credenciales desconectado realiza un paso de validación durante el inicio para garantizar que puede atender correctamente las solicitudes de los clientes. Como parte de este proceso, el proxy valida cada configuración definida en AppSettings:SecureStoreConfigurations. La lógica de validación específica aplicada depende del tipo de almacén de credenciales configurado.

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

Posibles causas de que la aplicación no se inicie

Varios problemas pueden impedir que se inicie la aplicación Credentials Proxy . A continuación se muestran las causas comunes y cómo identificarlas.

• El grupo de aplicaciones IIS no se ha iniciado (Windows). Si el proxy está alojado en IIS, comprueba que el grupo de aplicaciones asociado a él se está ejecutando. Puedes comprobarlo en el Administrador de IIS en la sección Grupos de aplicaciones .
• Configuración no válida en appsettings.Production.json. Un archivo de configuración no válido o incompleto puede hacer que el proxy falle durante el inicio. Consulta los ejemplos en la sección Ejemplos de configuración para obtener más detalles.
• Configuración no válida en AppSettings:SecureStoreConfigurations. La sección SecureStoreConfigurations define cómo se conecta el proxy y valida los almacenes de credenciales. Si alguna de estas entradas tiene un formato incorrecto 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 coinciden con el tipo de almacén de credenciales que estás utilizando. El uso de parámetros o claves incorrectos puede hacer que la validación de inicio falle.
  • No se puede acceder al almacén. Si el almacén de credenciales configurado depende de un almacén externo (por ejemplo, CyberArk, BeyondTrust u otros), el inicio puede fallar si el proxy no puede alcanzarlo o autenticarse con él.
• Otras cuestiones relacionadas con la infraestructura.

Depuración

Al depurar el proxy de credenciales, el objetivo es eliminar tantas variables como sea 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 parámetro "UseInMemorySecureStore": "true", en AppSettings.
  • Añade lo siguiente en AppSettings:SecureStoreConfigurations:

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

  • El proxy ya no debería tener problemas relacionados con la configuración. Si sigue sin poder iniciarse, lo más probable es que la causa esté relacionada con la infraestructura.
• Una vez que hayas confirmado que el proxy se inicia correctamente utilizando 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 tienda.

    Si la aplicación no se inicia, deberías encontrar los registros en:

    • El Visor de eventos de Windows.

    • El directorio de registros configurado del proxy.

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

    Para ayudar con la depuración en estos casos, puedes deshabilitar temporalmente la validación del almacén seguro añadiendo este parámetro en AppSettings:

    "SkipValidateSecureStoreConfigurations": true

    Nota: Este parámetro solo debe utilizarse con fines de depuración. La validación de inicio existe para garantizar que la configuración de tu proxy sea correcta y segura.