Orchestrator Credentials Proxy のデバッグ

ログ

既定では、Orchestrator Credentials Proxy はすべての例外、および初回起動とシャットダウンの情報をログに記録します。

Credentials Proxy が実際に 200 件の要求を記録しているかどうかを確認するには、ローカル サーバーで Orchestrator Credentials Proxy を起動して Swagger に移動し、正常性 (非認証) エンドポイント api/v1/Health を実行します。これで、要求がログに記録されます。

注:appsettings ファイルに変更を加えた後は毎回、Credentials Proxy を再起動する必要があります。

以下の手順を実行しても、起動とシャットダウン以外の追加のログがない場合は、要求が Orchestrator Credentials Proxy に達していないことを意味します。この原因として最も可能性が高いのは、Orchestrator Cloud ロボットと Orchestrator Credentials Proxy マシンのインフラストラクチャまたはネットワークの問題です。

イベント ビューアー

Orchestrator Credentials Proxy バージョン 2.0.0 以降では、ログはすべて Windows イベント ビューアーに表示されます。

ログ ファイルの保存先を変更する

ログ ファイルのパスを変更するには、appsettings.production.json ファイルを開き、以下のコードを使用します。 C:/dev/logs は目的のパスに置き換えることができます。

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

追加のログ

注: この手順は、デバッグにのみ使用してください。これらの変更を行うと過剰なログが生成されるため、この手順が完了したら変更を元に戻してください。

既定のログ レベルは次のようになります。

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

より多くのログを取得する場合 (プロキシに着信するすべての要求を確認する場合など) は、appsettings.Production.json ファイルを編集し、以下を追加する必要があります。

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

Information が十分ではなく、ログ レベルを上げるか下げる場合は、LogLevels の値を .Net から取得します。 詳しくは、Microsoft のドキュメントをご覧ください。appsettings.json ファイルは次のようになります。

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

appsettings ファイルを変更した後、Orchestrator Credentials Proxy を再起動します。

InMemoryStore を使用してテストする

デバッグ時に問題が発生し、別の種類の資格情報ストアで確認する場合は、InMemorySecureStore の種類の Orchestrator Credentials Proxy を使用できます。

注: この手順は、テストの目的でのみ使用してください。

InMemorySecureStore の種類を有効化するには、appsettings.production.json ファイルを開き、AppSettings セクションに移動して、"UseInMemorySecureStore": "true" パラメーターを追加します。

非接続のプロキシに対して有効化するには、以下のパラメーターを SecureStoreConfigurations セクションにも含めます。

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

接続状態のプロキシが接続できない場合

Orchestrator Credentials Proxy 接続を設定して Orchestrator にリンクしようとしたときに、次のエラー メッセージが表示されることがあります。

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

接続プロセス中に、Orchestrator は/api/v1/Healthプロキシ エンドポイントに対して単純な GET 要求を実行します。

この要求の目的は、Orchestrator クラウド環境からプロキシにアクセス可能であることを確認することです。この要求が失敗する場合、Orchestrator がプロキシにアクセスできないことを示し、接続チェックに合格しません。

一般的な問題

• Orchestrator Credentials Proxy が起動しません。

  • Orchestrator Credentials Proxy がインストールされているサーバーに移動します。

  • IIS で、Credentials Proxy アプリケーションが実行されていることを確認します。

  • 同じサーバーでブラウザーを開き、Credentials Proxy の URL にローカルでアクセスできることを確認します。

• 接続に有効な HTTPS/SSL 証明書がありません。Orchestrator と OCP 間のすべての通信はセキュリティで保護されている必要があります。

  • Credentials Proxy で有効な HTTPS/SSL 証明書が使用されていることを確認します。

  • (任意) Orchestrator Credentials Proxy の前面にロード バランサーが構成されている場合は、ロード バランサーでもセキュリティで保護された HTTPS 接続が使用されていることを確認します。

• Orchestrator Credentials Proxy が、ファイアウォール、VPN、または同様のネットワーク制限によってブロックされています。Orchestrator から Credentials Proxy にアクセスできない場合は、ネットワーク構成を確認します。
  • Orchestrator の送信 IP が適切にホワイトリストに登録されていることを確認します。詳しくは、「Orchestrator の送信 IP アドレス」をご覧ください。
    注: 組織に複数のテナントがある場合は、各テナントが異なるリージョンでホストされ、異なる IP アドレスを使用している可能性があります。各テナントを再確認してください。
• サーバー時間が正しくないために認証されていないエンドポイントの問題。
  • 認証されていないエンドポイントが失敗する場合は、サーバー時間が正しく設定されていない可能性があります。システム クロックが不正確であると、サーバーは JWT トークンを無効と解釈することがあります。

調査手順

1. IIS で、Orchestrator Credentials Proxy が実行されていることを確認します。
2. ブラウザーで、Credentials Proxy の URL にアクセスでき、Credentials Proxy が正しく読み込まれることを確認します。
3. ブラウザーで、Credentials Proxy の URL がセキュリティで保護されていることを確認します。
4. Credentials Proxy マシンで、トラブルシューティングのためにログ レベルを Info に引き上げます。調査が完了したら、忘れずにこの変更を元に戻してください。
5. 健全性エンドポイントをローカルでテストします。Credentials Proxy マシンで Swagger を開くか、Postman などのツールを使用して、以下に要求を送信します。

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

   正常な応答は、プロキシがアクセス可能で、ローカルで動作していることを示します。

6. VPN 内でアクセスをテストします。同じ VPN 内の別のマシン (クライアントのノート PC やクライアントのロボット端末など) から、Credentials Proxy の URL にアクセスできることを確認します。同じ /api/v1/Health エンドポイントに要求を送信します。

   • これが機能する場合、Credentials Proxy は VPN の内部からアクセス可能です。

   • 機能しない場合、クライアント側で内部ネットワークまたはルーティングの問題を解決する必要があります。

7. パブリック アクセスが可能かどうかをテストします。
8. VPN 内にないマシンで、/api/v1/Health エンドポイントを確認します。

   • これが機能する場合、Credentials Proxy は VPN の外部からアクセス可能です。

   • 機能しない場合、クライアント側で内部ネットワークまたはルーティングの問題を解決する必要があります。

9. Orchestrator クラウドからの接続をテストします。同じプロキシ URL にリンクされた新しい Credentials Proxy を作成します。

   • 作成に成功した場合、コネクションを削除できます。

   • 作成に失敗した場合、何らかの要因によって Orchestrator と資格情報プロキシ間の通信がブロックされています。

     注: この時点で、Credentials Proxy は、ファイアウォールの制限や IP ホワイトリストへの登録なしでパブリックにアクセスできるはずです。
10. Orchestrator テナントの IP アドレスのリストを取得します。

11. Credentials Proxy にアクセスするための許可リストに IP を追加します。

12. VPN の外部のマシンから、/api/v1/Health エンドポイントを再度テストします。IP が許可リストに追加されていないため、これは機能しないはずです。
13. Orchestrator Cloud で、Credentials Proxy をもう一度作成してみます。
    • すべての手順が正しく完了すれば、作成は成功するはずです。
    • まだ作成に失敗する場合は、ファイアウォールまたは VPN のルールによって Orchestrator と Credentials Proxy 間の通信が妨げられている問題が考えられます。
14. 問題が解決しない場合は、上記の手順を慎重に繰り返し、各構成ポイントを確認します。
15. この問題が解決したら、Credentials Proxy マシンのログ レベルを元の設定に戻します。

非接続のプロキシが起動しないか、ログを記録しない

非接続の Credentials Proxy は起動時に検証手順を実行して、クライアント要求を正しく処理できることを確認します。このプロセスの一部として、Credentials Proxy は AppSettings:SecureStoreConfigurations で定義されている各設定を検証します。適用される具体的な検証ロジックは、設定されている資格情報ストアの種類によって異なります。

場合によっては、プロキシの起動に失敗する根本原因が起動プロセスの非常に早い段階で発生するために、アプリケーションがログ イベントを生成または書き込めるポイントに達しないことがあります。

アプリが起動しない考えられる原因

、Credentials Proxy アプリケーションが起動しない場合、さまざまな原因が考えられます。以下に、一般的な原因とその特定方法を示します。

• IIS アプリケーション プールが起動していない (Windows)。プロキシが IIS でホストされている場合は、プロキシに関連付けられているアプリケーション プールが実行されていることを確認します。これは、IIS マネージャーの [アプリケーション プール] セクションで確認できます。
• appsettings.Production.json の設定が無効である。構成ファイルが無効または不完全な場合、起動時にプロキシが失敗する可能性があります。詳しくは、「設定のサンプル」セクションの例をご覧ください。
• AppSettings:SecureStoreConfigurations の設定が無効である。SecureStoreConfigurations セクションでは、プロキシが資格情報ストアに接続して検証する方法を定義します。これらのエントリのいずれかの形式が正しくないか不完全な場合、アプリケーションは起動しません。
  • 設定に無効なパラメータがある。すべての構成パラメーターが、使用している資格情報ストアの種類と一致していることを確認します。間違ったパラメーターやキーを使用すると、起動時の検証に失敗する可能性があります。
  • コンテナーにアクセスできない。設定されている資格情報ストアが外部コンテナー (CyberArk、BeyondTrust など) に依存している場合、プロキシがその外部コンテナーにアクセスできないか認証できないと、起動に失敗することがあります。
• インフラストラクチャに関連するその他の問題がある。

デバッグ

Credentials Proxy をデバッグする際の目標は、複雑な構成をテストする前にできる限り多くの不確定要素を排除することです。

• まず、InMemorySecureStore の種類で最小限の構成を使用します。これにより、外部の依存関係を導入する前に、プロキシが正常に起動できることを確認できます。
  • AppSettings に "UseInMemorySecureStore": "true", パラメーターを追加します。
  • AppSettings:SecureStoreConfigurations に以下を追加します。

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

  • これでプロキシの構成関連の問題はなくなるはずです。まだ起動に失敗する場合、原因はインフラストラクチャに関連すると考えられます。
• メモリ内構成を使用してプロキシが正常に起動することを確認したら、実際の資格情報ストアの設定 (CyberArk、BeyondTrust など) に置き換えます。
  • 自身の環境とストアの種類に基づいて SecureStoreConfigurations セクションを更新します。

    アプリケーションの起動に失敗する場合、以下のいずれかの場所でログを確認できます。

    • Windows イベント ビューアー

    • プロキシで構成されているログ ディレクトリ

  • アプリケーションが起動せず、ログが生成されない場合、問題は環境内のインフラストラクチャまたは権限に関連している可能性があります。

    このような場合に容易にデバッグできるようにするには、次のパラメーターを AppSettings に追加して、Secure Store の検証を一時的に無効化します。

    "SkipValidateSecureStoreConfigurations": true

    注: このパラメーターはデバッグ目的でのみ使用してください。起動時の検証は、プロキシの構成が適切でセキュリティで保護されていることを確認するために存在します。