• /
  • EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

秘密管理

シークレット管理を使用すると、構成ファイルにプレーン テキストとして機密データ (パスワードなど) を書き込むことなく、機密データ (パスワードなど) を使用するようにエージェントとオンホストの統合を構成できます。現在、Hashicorp Vault、AWS KMS、CyberArk、New Relic CLI の難読化およびカスタム コマンドがサポートされています。

詳しくは、NerdBytesのビデオ(5分12秒)をご覧ください。

秘密の定義

設定用YAMLファイルでシークレットを使用するには

  1. variablesセクションを定義します。各エントリはシークレットオブジェクトの名前です。
  2. 各エントリには、秘密のソースと、それらの秘密を取得するための適切な構成を含めてください。
  3. 一般的な構成セクションで、シークレットオブジェクトのプロパティによって自動的に置き換えられる${variable.property}プレースホルダーを設定します。シークレットオブジェクトは、単純な文字列またはjsonオブジェクトとして定義できます。

重要

秘密の検索に失敗すると、インフラストラクチャ・エージェントが実行に必要なすべてのデータを持っていないため、統合は実行されません。

たとえば、次の構成では、Vaultからcredsという名前のオブジェクトを取得します(シークレットのオブジェクト名を定義できます)。保存されたオブジェクトが、 userという名前のプロパティとpasswordという名前の別のプロパティを持つ有効なJSONであると仮定します。それらを使用して、Nginxオンホスト統合からのstatus_urlプロパティの基本HTTPクレデンシャルを設定します。

variables:
creds:
vault:
http:
url: http://my.vault.host/v1/newengine/data/secret
headers:
X-Vault-Token: my-vault-token
integrations:
- name: nri-nginx
env:
METRICS: "true"
STATUS_URL: http://${creds.user}:${creds.password}@example.com/status
STATUS_MODULE: discover
REMOTE_MONITORING: true
interval: 30s
labels:
env: production
role: load_balancer

ヒント

変数からは、単純な文字列と有効なJSONオブジェクトの両方を取得することができます。\ JSONオブジェクトを使用する場合は、キーと値の両方がダブルクオートで囲まれていることを確認してください。

環境変数の使用

環境変数は、 {{MY_ENV_VAR}}表記でvariablesセクションに使用できます。その際、環境変数が展開され、実行時にその値が置き換えられます。

トークンや難読化キーなどの機密性の高い値が設定ファイルに含まれないようにするには、この方法を使用します。

オンホストの統合設定ファイルで環境変数を使用する場合、 passthrough_environment 設定を定義する必要があります。

秘密の変数

variablesセクションの下の各構成でシークレットを定義します。各エントリは、取得したシークレットのプロパティを格納するユーザー定義のシークレット名です。各変数には、次のプロパティを含めることができます。

YAMLキー

説明

ttl

タイプ文字列

シークレットが更新されるまでの時間。これは、数値の後に時間単位( sm 、またはh )を続けることができます。

例: 30s10m1h

デフォルト: 1h

aws-kms

AWS KMSのシークレット検索の設定

vault

ヴォールトシークレットの検索設定

cyberark-cli

CyberArkのコマンドラインインターフェイスの設定

cyberark-api

CyberArk REST APIの設定

obfuscated

New Relic CLIの難読化

AWS KMSの秘密

Amazon KMSからシークレットを取得するには、 aws-kmsセクションで次のプロパティを設定できます。すべてのフィールドが必須というわけではありません。たとえば、エンコードされたKMS文字列を提供するには、 datafile 、またはhttpのいずれかが必要になります。

YAMLキー

説明

data

タイプ文字列

復号化するBase64エンコードされたKMS文字列

file

タイプ文字列

復号化するBase64エンコードされたKMS文字列を含むファイルへのパス

http

タイプYAMLプロパティ

Base64でエンコードされたKMS文字列を復号化するように要求するために使用するHTTP構成。詳細については、 Vault httpを参照してください。

credential_file

タイプ文字列

AWS認証情報ファイルへのパス

config_file

タイプ文字列

AWS設定ファイルへのパス

region

タイプ文字列

AWS KMSリージョン

type

タイプ:文字列( plainequal 、またはjson

秘密の値のフォーマット。

  • plain:宛先変数に直接格納される生の文字列。

  • equal:オブジェクトプロパティとして宛先変数に格納されるkey=propertyの1行の文字列。

  • json:プロパティとして宛先変数に格納されるJSONオブジェクト。

    タイプplainまたはjsonのシークレットはドット表記を使用します。たとえば、 ${mysecret.nestedkey}

次の例では、AWSKMSからプレーンなパスワード文字列を取得できます。提供されたdataエンコード文字列から復号化する必要があります。

variables:
myPassword:
aws-kms:
data: T0hBSStGTEVY
region: ap-southeast-2
credential_file: "./my-aws-credentials-file"
config_file: "./my-aws-config-file"
type: plain

ヴォールトの秘密

Vaultは、Vaultへの接続に使用されるHTTP構成を含むhttpフィールドを有効にする必要があります。httpエントリには、次のエントリを含めることができます。

YAMLキー

説明

url

タイプ文字列

データを要求するURL

tls_config

タイプYAMLプロパティ

TLSの構成プロパティを使用する

headers

タイプYAMLマップ

リクエストヘッダー

tls_configプロパティ

重要

シークレットはドット表記を使用する必要があります(例: ${mysecret.nestedkey}

YAMLキー

説明

enable

タイプブーリアン

TLSを有効にする

デフォルト: false

insecure_skip_verify

タイプブーリアン

サーバーの証明書チェーンとホストの検証をスキップする

デフォルト: false

min_version

型。UInt16

受け入れ可能なSSL/TLSの最小バージョン

デフォルト: 0 (TLSバージョン1.0を使用)

max_version

型。UInt16

許容される最大のSSL/TLSバージョン

デフォルト: 0 (TLSバージョン1.3を使用)

ca

タイプ文字列

TLS証明書

""

次の例では、セキュリティで保護されたサーバーから Vault トークンを使用してシークレットを取得し、サーバー証明書の検証をスキップします。

variables:
mydata:
vault:
http:
url: https://my.vault.host/v1/newengine/data/secret
headers:
X-Vault-Token: my-vault-token
tls_config:
insecure_skip_verify: true

CyberArkのコマンドラインインターフェイス

CyberArkのコマンドラインインターフェイス(CLI)からシークレットを取得するには、以下の構成を使用します。すべてのキーが必要です。

YAMLキー

説明

cli

タイプ:文字列

CyberArk CLI実行ファイルのフルパス

デフォルト:""

app-id

タイプ:文字列

秘密保持者のアプリケーションID

デフォルト:""

safe

タイプ:文字列

秘密が詰まった金庫

デフォルト:""

folder

タイプ:文字列

秘伝書の入ったフォルダ

デフォルト:""

object

タイプ:文字列

秘密が関連付けられているオブジェクト

デフォルト:""

次の例では、コマンドライン・インターフェースを使ってCyberArkの秘密を取得します。

variables:
credentials:
cyberark-cli:
cli: /full/path/to/clipasswordsdk
app-id: my-appid
safe: my-safe
folder: my-folder
object: my-object

CyberArk REST API

CyberArk REST APIを使用してシークレットを取得するには、HTTP構成を含むhttpキーが必要です。httpキーにはこれらのサブキーが含まれています。必要なのはurlのみです。

YAMLキー

説明

url

タイプ文字列

データを要求するURL、このキーが必要です。

デフォルト:なし

tls_config

タイプYAMLプロパティ

TLSの構成プロパティを使用する

headers

タイプYAMLマップ

リクエストヘッダー

次の例では、CyberArk REST APIを使用して、サーバー証明書の検証を省略してシークレットを取得しています。

variables:
credentials:
cyberark-api:
http:
url: https://hostname/AIMWebService/api/Accounts?AppID=myAppID&Query=Safe=mySafe;Object=myObject
tls_config:
insecure_skip_verify: true

上記の例を参考にして、ユーザー名とパスワードを次のように呼び出します。

USERNAME: ${credentials.user}
PASSWORD: ${credentials.password}

注: Microsoft SQL Server の場合、Windows 認証ユーザー ログインを使用する場合は、 USERNAME前にドメインを付ける必要があります。 例えば:

USERNAME: <domain>\${credentials.user}

New Relic CLIの難読化

重要

可能な場合は、単純な難読化ではなく、サポートされているシークレット プロバイダーのいずれかを使用することをお勧めします。 単純な難読化では、プロセスを元に戻すことができるため、資格情報の機密性が保証されません。

下記のガイドラインを参照して、環境変数を定義し、設定ファイルに難読化キーを持たないようにしてください。

Windowsホストでは、コマンドプロンプトウィンドウではなく、Powershellを使用してください。コマンドプロンプトウィンドウでは、引用符が予期せぬ方法で処理されることがあるからです。

ヒント

インフラストラクチャ エージェント 1.14.0 以降が必要です

New Relic CLI の obfuscate コマンドを使用すると、インフラストラクチャ エージェントやオンホストの統合設定ファイル内の機密情報を不明瞭にすることができます。

ステップ

newrelic agent config obfuscate --value '<plain_text_config_value>' --key '<obfuscation_key>'
  • 以下の例に示すように、cliコマンドの結果をobfuscatedセクションのtext引数にコピーします。
  • 構成YMLファイルで複数の値を参照する必要がある場合は、JSONブロックを難読化できます。Windowsホストでは、引用符""を円記号でエスケープする必要がある場合があることに注意してください。例: '{\"attribute\":\"value\"... 。さらに、コマンドプロンプトウィンドウでは予期しない方法で引用符を処理できるため、コマンドプロンプトウィンドウではなく、WindowsホストでPowershellを使用してください。
newrelic agent config obfuscate --value '{"attribute":"value","attribute2":"value2"}' --key '<obfuscation_key>'

YAMLキー

説明

キー

タイプ文字列

New Relic CLI を使用してクリアテキスト値を難読化する際に使用する文字列

デフォルト:なし

secret

タイプ文字列

newrelic-cliコマンドの出力結果

デフォルト:なし

Integrations configuration example

次の例では、New Relic CLI を使用して難読化された Nginx のユーザー名とパスワードを取得できます。 この例では、難読化された値が JSON ブロックであるため、資格情報を取得するときにドット表記を使用します。

variables:
creds:
obfuscated:
key: 'random_key_used_in_cli'
secret: 'obscured_output_from_cli'
integrations:
- name: nri-nginx
env:
METRICS: "true"
STATUS_URL: http://${creds.user}:${creds.password}@example.com/status
STATUS_MODULE: discover
REMOTE_MONITORING: true
interval: 30s
labels:
env: production
role: load_balancer

以下の例のように、難読化の引数に環境変数を使用することをお勧めします。

variables:
creds:
obfuscated:
key: {{OBFUSCATION_KEY}}
secret: {{OBFUSCATION_TEXT}}
integrations:
- name: nri-nginx
env:
METRICS: "true"
STATUS_URL: http://${creds.user}:${creds.password}@example.com/status
STATUS_MODULE: discover
REMOTE_MONITORING: true
interval: 30s
labels:
env: production
role: load_balancer

Agent configuration example

この例では、プロキシの詳細 (ユーザー、パスワード、ホスト) を含む文字列を取得できます。

variables:
obfuscated_proxy:
obfuscated:
key: 'random_key_used_in_cli'
secret: 'obscured_output_from_cli'
proxy: ${obfuscated_proxy}

カスタムコマンド

重要

command 構成には、インフラストラクチャ エージェント 1.41.0 以降が必要です。環境要件に基づいて、構成された command を実行するために必要な権限がエージェントにあることを確認してください。

同じホストで使用できるカスタム コマンドからエージェントまたは統合の構成を読み込むことができます。インフラストラクチャ エージェントは、構成を最初に command 出力からロードするタイミングを検出し、 ttl の更新時間に基づいて値を更新し続けます。

コマンドの予期される出力形式は、JSON または String のいずれかです。

JSON

次の JSON 構造は、定義された commandからのメイン出力 (stdout) として想定されます。

{
"data": {
"myKey": "myValue"
},
"ttl": "24h"
}
  • 最上位の data フィールドは必須です。
  • 最上位の ttl フィールドは必須です。

これは、 ${myVariable.key} 表記を使用して任意の構成ファイルで使用できます。次の例では、 my-custom-auth コマンドが domain パラメータを指定して実行され、結果の token エージェント構成としてロードされます。

variables:
myToken:
command:
path: '/path/to/my-custom-auth-json'
args: ["--domain", "myDomain", "--other_param", "otherValue"]
ttl: 24h
# my-custom-auth output example: {"data":{"token":"XXXXYYYYZZZZ"}, "ttl": "24h"}
# the `token` result can be included as ${myToken.token} in any configuration.
http:
headers:
"Proxy-Authorization": ${myToken.token}

文字列(テキスト/プレーン)

コマンド出力がプレーン文字列の場合は、構成内で ${myVar} 表記を使用して参照できます。

例:

variables:
myToken:
command:
path: '/path/to/my-custom-auth-string'
args: ["arg1", "arg2"]
ttl: 24h
# my-custom-auth output example: "XXXXYYYYZZZZ"
# the `token` result can be included as ${myToken} on any configuration.
http:
headers:
"Proxy-Authorization": ${myToken}
Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.