構成ファイルにプレーンテキストでシークレットを保存したくない場合は、シークレット管理パッケージを使用できます。パッケージを利用してユーザー指定の実行可能ファイルを呼び出し、シークレットの取得と復号化を処理できます。よってメモリにロードされます。)に依存し、好みの認証方法を選択してイニシャルトラストを確立できます。パッケージされているため、便利です。フィールドの値としてシークレットを示します。あらゆる構成バックエンドおよび環境変数でサポートされています。サポートされています。最初にメイン構成をロードし、シークレットを復号化した後にそれをリロードします。設定で使用できないことを意味します。シークレットは常に文字列です。シークレットを使用して整数またはブール値を設定することはできません。値全体である必要があります。以下がシークレットハンドルとして検出されないことを意味します。つのシークレットがあります。これらはシークレットの_ハンドル_であり、それぞれがシークレット管理バックエンド内でシークレットを一意に識別します。構成が有効である限り、あらゆる文字が許可されます。これは、引用符をエスケープする必要があることを意味します。エスケープする必要はありません。シークレットはオートディスカバリーテンプレート変数が解決された後に解決されます。シークレットハンドルで使用できます。ENC[db_prod_password_%%host%%]実行可能ファイルの提供シークレットを取得するには、シークレット管理バックエンドに対してシークレットを認証してフェッチできる実行可能ファイルを提供する必要があります。メモリ内にシークレットを内部的にキャッシュして、呼び出しの回数を減らします(たとえば、コンテナ化された環境で役立ちます)。含むチェック構成ファイルにアクセスするたびに実行可能ファイルを呼び出します。メモリにロードされているシークレットは、実行可能ファイルへの追加の呼び出しをトリガーしません。シークレットハンドルを含む新しいチェックを動的にロードした場合(オートディスカバリーからなど)、後で実行可能ファイルに対する追加の呼び出しを行う可能性があるということです。プロセスモニタリングは独自のプロセス/サービスで実行され、プロセスはメモリを共有しないため、それぞれがシークレットをロード/復号化できる必要があります。回呼び出すことがあります。回行われる可能性があります。設計上、ユーザー提供の実行可能ファイルは、ユーザーが必要とする可能性のあるエラー処理メカニズムを実装する必要があります。再起動する必要があります。ユーザー提供の実行可能ファイルに依存することには、複数の利点があります。シークレットハンドルのないパラメーターをメモリに読み込まないことが保証される。再構築せずに任意のシークレット管理バックエンドを自由かつ柔軟に使用できる。自分のシークレット管理バックエンドまでのイニシャルトラスト問題を解決できる。これは、各ユーザーの好みの認証方法を活用し、継続的なインテグレーションワークフローに適合する形で発生します。次の変数を設定します。実行可能ファイルを実行します。実行パターンが異なります。して設定される実行可能ファイルは以下である必要があります。グループまたはその他の権限を持っていない。所有者に対して少なくとも実行権限を持っている。して設定される実行可能ファイルは以下である必要があります。実行に使用したユーザー)の読み取り/実行を持っている。ddagentuser)以外のユーザーまたはグループの権限を持っていない。スクリプトは機能しません)。同じ環境変数を共有します。機密情報を出力しないでください。実行可能ファイルの標準エラー出力をログします。標準出力に出力します。以外の場合、現在復号化されているインテグレーション構成はエラーと見なされ、ドロップされます。ペイロードを標準入力から受信します。1.0)を含む文字列です。各文字列は、取得するシークレットに対応する構成からのハンドルです。ペイロードを標準出力に出力することが期待されます。