Orchestrator Credentials Proxy のデバッグ

ログ

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

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

注:

appsettings ファイルに変更を加えたら、毎回資格情報プロキシを再起動する必要があります。

以下の手順を実行しても、起動とシャットダウン以外の追加のログがない場合は、要求が 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 Cloud からの接続をテストします。同じプロキシ URL にリンクされた新しい Credentials Proxy を作成します。
   • 作成に成功した場合、コネクションを削除できます。
   • 作成に失敗した場合、何らかの要因によって Orchestrator と資格情報プロキシ間の通信がブロックされています。
     注:

     この時点で、資格情報プロキシは、ファイアウォールの制限や 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
```

注:

このパラメーターはデバッグ目的でのみ使用してください。起動時の検証は、プロキシ構成が適切かつ安全であることを確認するために存在します。