シークレット管理

このドキュメントは最新ではありません。最新版はこちらをクリックして英語版をご覧ください。

概要

Datadog Agent は、次のシークレット管理ソリューションと統合することで、シークレットを安全に管理するのに役立ちます。

API キーやパスワードのような機密値を構成ファイル内にプレーンテキストでハードコーディングする代わりに、Agent は実行時に動的にそれらを取得できます。構成内でシークレットを参照するには、ENC[<secret_id>] 表記を使用します。シークレットは取得され、メモリにロードされますが、ディスクに書き込まれたり、Datadog バックエンドに送信されたりすることはありません。

注: secret_backend_command のような secret_* 設定では、ENC[] 構文は使用できません。

シークレットを取得するためのオプション

オプション 1: シークレットを取得するためにネイティブ Agent サポートを使用

注: Agent バージョン 7.76 以降、ネイティブなシークレット管理が FIPS 対応 Agent で利用可能です。

Agent バージョン 7.70 以降、Datadog Agent では複数のシークレット管理ソリューションをネイティブにサポートしています。datadog.yaml に新しい 2 つの設定 secret_backend_type と secret_backend_config が導入されました。

secret_backend_typeは、使用するシークレット管理ソリューションを指定するために使用され、secret_backend_config にはそのソリューションに関連する追加の設定が保持されます。

# datadog.yaml

secret_backend_type: <backend_type>
secret_backend_config:
  <KEY_1>: <VALUE_1>

注: コンテナ化された環境で Datadog を実行している場合、Cluster Agent では、ネイティブなシークレットの取得をサポートするために Agent 7.77 以降が必要です。以前のバージョンでは、代わりにオプション 2 またはオプション 3 を使用してください。

より具体的なセットアップ手順は、使用するバックエンドタイプによって異なります。詳細情報については、以下の該当するセクションを参照してください。

次の AWS サービスがサポートされています。

secret_backend_type 値AWS サービス
aws.secretsAWS Secrets Manager
インスタンスプロファイルのセットアップ

AWS によりすべての環境変数とセッションプロファイルが処理されるため、Datadog では インスタンスプロファイルメソッド を使用してシークレットを取得することを推奨しています。このための詳細な指示は、公式の AWS Secrets Manager のドキュメント で確認できます。

構成例

    AWS Secrets を使用して、次の設定に基づいてシークレットを解決するように Datadog Agent を設定します。

    # datadog.yaml
secret_backend_type: aws.secrets
secret_backend_config:
  aws_session:
    aws_region: {regionName}

    環境変数を使用する場合、設定を次のように JSON に変換します。

    DD_SECRET_BACKEND_TYPE="aws.secrets"
DD_SECRET_BACKEND_CONFIG='{"aws_session":{"aws_region":"<AWS_REGION>"}}'

    AWS Secrets を使用するように Agent を設定した後、ENC[secretId;secretKey] を使用して設定内の任意のシークレットを参照できます。

    ENC 表記は次のように構成されています。

    • secretId: シークレットの「フレンドリ名」(たとえば、/DatadogAgent/Production) または Amazon Resource Name (たとえば、arn:aws:secretsmanager:us-east-1:123456789012:secret:/DatadogAgent/Production-FOga1K) のいずれかです。
      • 注: AWS 資格情報または sts:AssumeRole 資格情報が定義されている異なるアカウントからシークレットにアクセスする場合、完全な Amazon Resource Name 形式が必要です。
    • secretKey: 使用する AWS シークレットからの JSON キーです。

    AWS Secrets Manager は、1 つのシークレット内に複数のキーと値のペアを保存できます。Secrets Manager を使用したバックエンド設定からは、シークレットに定義されたすべてのキーにアクセスできます。

    たとえば、シークレット ID My-Secrets に次の 3 つの値が含まれているとします。

    {
    "prodApiKey": "datadog api key to use",
    "anotherSecret1": "value2",
    "anotherSecret2": "value3",
}

    次に示すのは、AWS Secrets を使用して My-Secrets から API キーを取得する datadog.yaml 構成ファイルの完全な例です。

    api_key: ENC[My-Secrets;prodApiKey]

secret_backend_type: aws.secrets
secret_backend_config:
  aws_session:
    aws_region: us-east-1

    AWS Secrets を使用して、次の設定に基づいて Helm 内のシークレットを解決するように Datadog Agent を設定します。

    インテグレーションチェック
    datadog:
  confd:
  # This is an example
    <INTEGRATION_NAME>.yaml: |-
      ad_identifiers:
        - <SHORT_IMAGE>
      instances:
        - [...]
          password: "ENC[secretId;secretKey]"
  env:
   - name: DD_SECRET_BACKEND_TYPE
     value: "aws.secrets"
   - name: DD_SECRET_BACKEND_CONFIG
     value: '{"aws_session":{"aws_region":"<AWS_REGION>"}}'
agents:
  rbac:
    # IAM role ARN required to grant the Agent permissions to access the AWS secret
    serviceAccountAnnotations:
      eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
    AWS シークレットにアクセスするための権限を Agent に付与するには、 serviceAccountAnnotations を含める必要があります。

    クラスターチェック: クラスターチェックランナーが有効でない場合
    datadog:
  env:
   - name: DD_SECRET_BACKEND_TYPE
     value: "aws.secrets"
   - name: DD_SECRET_BACKEND_CONFIG
     value: '{"aws_session":{"aws_region":"<AWS_REGION>"}}'
agents:
  rbac:
    # IAM role ARN required to grant the Agent permissions to access the AWS secret
    serviceAccountAnnotations:
      eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
clusterAgent:
  confd:
    # This is an example
    <INTEGRATION_NAME>.yaml: |-
      cluster_check: true
      instances:
        - [...]
          password: "ENC[secretId;secretKey]"
    クラスターチェック: クラスターチェックランナーが有効な場合
    datadog:
  env:
   - name: DD_SECRET_BACKEND_TYPE
     value: "aws.secrets"
   - name: DD_SECRET_BACKEND_CONFIG
     value: '{"aws_session":{"aws_region":"<AWS_REGION>"}}'
clusterAgent:
  confd:
  # This is an example
    <INTEGRATION_NAME>.yaml: |-
      cluster_check: true
      instances:
        - [...]
          password: "ENC[secretId;secretKey]"
clusterChecksRunner:
  enabled: true
  env:
   - name: DD_SECRET_BACKEND_TYPE
     value: "aws.secrets"
   - name: DD_SECRET_BACKEND_CONFIG
     value: '{"aws_session":{"aws_region":"<AWS_REGION>"}}'
  rbac:
    # IAM role ARN required to grant the Agent permissions to access the AWS secret
    serviceAccountAnnotations:
      eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>

    **あるいは、**Helm チャート v3.171.0 以上および Agent v7.70 以上の場合は、環境変数の代わりにネイティブの secretBackend.type および secretBackend.config フィールドを使用できます。例: datadog.secretBackend.type: "aws.secrets" および datadog.secretBackend.config.aws_session.aws_region: "<AWS_REGION>"。

    AWS Secrets を使用して、次の設定に基づいて、Datadog Operator と共にシークレットを解決するように Datadog Agent を設定します。

    インテグレーションチェック
    apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  [...]
  override:
    nodeAgent:
      env:
       - name: DD_SECRET_BACKEND_TYPE
         value: "aws.secrets"
       - name: DD_SECRET_BACKEND_CONFIG
         value: '{"aws_session":{"aws_region":"<AWS_REGION>"}}'
      # IAM role ARN is required to grant the Agent permissions to access the AWS secret
      serviceAccountAnnotations:
        eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
      extraConfd:
        configDataMap:
        # This is an example
          <INTEGRATION_NAME>.yaml: |-
            ad_identifiers:
              - <SHORT_IMAGE>
            instances:
              - [...]
                 password: "ENC[secretId;secretKey]"
    AWS シークレットにアクセスするための権限を Agent に付与するには、 serviceAccountAnnotations を含める必要があります。

    クラスターチェック: クラスターチェックランナーが有効でない場合
    apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  [...]
  override:
    nodeAgent:
      env:
       - name: DD_SECRET_BACKEND_TYPE
         value: "aws.secrets"
       - name: DD_SECRET_BACKEND_CONFIG
         value: '{"aws_session":{"aws_region":"<AWS_REGION>"}}'
      # IAM role ARN required to grant the Agent permissions to access the AWS secret
      serviceAccountAnnotations:
        eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
    clusterAgent:
      extraConfd:
        configDataMap:
        # This is an example
          <INTEGRATION_NAME>.yaml: |-
            cluster_check: true
            instances:
              - [...]
                password: "ENC[secretId;secretKey]"

    クラスターチェック: クラスターチェックランナーが有効な場合
    apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  [...]
spec:
  features:
    clusterChecks:
      useClusterChecksRunners: true
  override:
    [...]
    clusterChecksRunner:
      env:
       - name: DD_SECRET_BACKEND_TYPE
         value: "aws.secrets"
       - name: DD_SECRET_BACKEND_CONFIG
         value: '{"aws_session":{"aws_region":"<AWS_REGION>"}}'
      # IAM role ARN required to grant the Agent permissions to access the AWS secret
      serviceAccountAnnotations:
        eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
    clusterAgent:
      extraConfd:
        configDataMap:
        # This is an example
          <INTEGRATION_NAME>.yaml: |-
            cluster_check: true
            instances:
              - [...]
                password: "ENC[secretId;secretKey]"

    **あるいは、**Datadog Operator v1.25.0 以上および Agent v7.70 以上の場合は、環境変数の代わりにネイティブの secretBackend.type および secretBackend.config フィールドを使用できます。例: spec.global.secretBackend.type: "aws.secrets"、spec.global.secretBackend.config、および aws_session.aws_region: "<AWS_REGION>"。

    次の AWS サービスがサポートされています。

    secret_backend_type 値AWS サービス
    aws.ssmAWS Systems Manager Parameter Store
    インスタンスプロファイルのセットアップ

    AWS によりすべての環境変数とセッションプロファイルが処理されるため、Datadog では インスタンスプロファイルメソッド を使用してシークレットを取得することを推奨しています。このための詳細な指示は、公式の AWS Secrets Manager のドキュメント で確認できます。

    構成例

    AWS Systems Manager Parameter Store では、階層モデルがサポートされています。たとえば、次のような AWS Systems Manager Parameter Store のパスがあるとします。

    /DatadogAgent/Production/ApiKey = <your_api_key>
/DatadogAgent/Production/ParameterKey2 = ParameterStringValue2
/DatadogAgent/Production/ParameterKey3 = ParameterStringValue3

    パラメーターは次のように取得できます。

    # datadog.yaml
secret_backend_type: aws.ssm
secret_backend_config:
  aws_session:
    aws_region: us-east-1

api_key: "ENC[/DatadogAgent/Production/ApiKey]"
property1: "ENC[/DatadogAgent/Production/ParameterKey1]"
property2: "ENC[/DatadogAgent/Production/ParameterKey2]"

    次の Azure サービスがサポートされています。

    secret_backend_type 値Azure サービス
    azure.keyvaultAzure Keyvault
    Azure 認証

    Datadog では、Azure での認証にマネージドアイデンティティを使用することを推奨しています。これにより、クラウドリソースを AMI アカウントに関連付けることができ、datadog.yaml 構成ファイルにシークレットを記載する必要がなくなります。

    マネージドアイデンティティ

    Key Vault にアクセスするには、マネージドアイデンティティを作成し、仮想マシンに割り当てます。次に、そのアイデンティティがシークレットにアクセスできるように、Key Vault に適切なロールを割り当てます。

    構成例

    Azure Key Vault シークレットのバックエンド設定は、このスキーマに従って YAML 形式で構成されています。

    # datadog.yaml
secret_backend_type: azure.keyvault
secret_backend_config:
  keyvaulturl: {keyVaultURL}

    バックエンドのシークレットは、Datadog Agent の構成ファイル内で ENC[ ] を使用して参照されます。次に示すのは、プレーンテキストのシークレットを取得する必要がある例です。

    # datadog.yaml

api_key: "ENC[secretKeyNameInKeyVault]"

    Agent バージョン 7.74 以上で利用可能

    次の GCP サービスがサポートされています。

    secret_backend_type 値GCP サービス
    gcp.secretmanagerGCP Secret Manager
    GCP 認証とアクセスポリシー

    GCP Secret Manager の実装は、Google での認証に アプリケーションデフォルト資格情報 (ADC) を使用します。

    GCP Secret Manager とやりとりするには、Datadog Agent で使用されるサービスアカウント (仮想マシンのサービスアカウント、ワークロードアイデンティティ、ローカルでアクティブ化された資格情報など) が、secretmanager.versions.access の権限を有している必要があります。

    これは、事前定義されたロール Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) または同等の アクセス権 を持つカスタムロールを使用して付与できます。

    GCE または GKE ランタイムでは、ADC はインスタンスまたは Pod に添付されたサービスアカウントを通じて自動的に設定されます。添付されたサービスアカウントには、GCP Secret Manager にアクセスするための適切なロールが割り当てられている必要があります。さらに、GCE または GKE ランタイムは、cloud-platform OAuth アクセススコープ を必要とします。

    GCP の構成例

    GCP Secret Manager を使用して、次の設定に基づいてシークレットを解決するように Datadog Agent を設定します。

    # datadog.yaml
secret_backend_type: gcp.secretmanager
secret_backend_config:
  gcp_session:
    project_id: <PROJECT_ID>

    GCP Secret Manager を使用するように Agent を設定した後、ENC[secret-name] または ENC[secret-name;key;version;] を使用して設定内でシークレットを参照します。

    ENC 表記は次のように構成されています。

    • secret: GCP Secret Manager 内のシークレット名 (例: datadog-api-key)。
    • key: (オプション) JSON 形式のシークレットから抽出するキー。プレーンテキストのシークレットを使用している場合は、省略できます (例: ENC[secret-name;;version])。
    • version: (オプション) シークレットのバージョン番号。指定しない場合、latest バージョンが使用されます。
      • バージョン構文の例:
        • secret-key - 暗黙の latest バージョン
        • secret-key;;latest - 明示的な latest バージョン
        • secret-key;;1 - 特定のバージョン番号

    たとえば、GCP シークレット名が datadog-api-key で、2 つのバージョンと datadog-app-key があるとします。

    # datadog.yaml
api_key: ENC[datadog-api-key;;1] # specify the first version of the api key
app_key: ENC[datadog-app-key] # latest version

secret_backend_type: gcp.secretmanager
secret_backend_config:
  gcp_session:
    project_id: <PROJECT_ID>

    JSON 形式のシークレットの場合、シークレット名 datadog-keys に以下が含まれるとします。

    {
  "api_key": "your_api_key_value",
  "app_key": "your_app_key_value"
}

    特定のキーを次のように参照します。

    # datadog.yaml
api_key: ENC[datadog-keys;api_key;1] # specify the first version of the api key 
app_key: ENC[datadog-keys;app_key] # latest

secret_backend_type: gcp.secretmanager
secret_backend_config:
  gcp_session:
    project_id: <PROJECT_ID>
    シークレットのバージョン管理

    GCP Secret Manager ではシークレットバージョンがサポートされています。Agent の実装でも、; 区切りを使用してシークレットのバージョン管理をサポートしています。バージョンが指定されていない場合、latest バージョンが使用されます。

    JSON シークレットのサポート

    Datadog Agent では、; 区切りを使用して、JSON 形式のシークレットから特定のキーを抽出することができます。

    • datadog;api_key - 暗黙の latest を使用して、datadog シークレットから api_key フィールドを抽出します。

    • datadog;api_key;1 - バージョン 1 の datadog シークレットから api_key フィールドを抽出します。

    次の HashiCorp サービスがサポートされています。

    secret_backend_type 値HashiCorp サービス
    hashicorp.vaultHashiCorp Vault (Secrets Engine バージョン 1 および 2)
    HashiCorp Vault のセットアップ方法
    1. HashiCorp Vault を実行します。詳細については、公式の HashiCorp Vault ドキュメント を参照してください。
    2. Vault からシークレットを取得するための権限を付与するポリシーを記述します。*.hcl ファイルを作成し、Secrets Engine バージョン 1 を使用している場合は、次の権限を含めます。
    path "<your mount path>/<additional subpath>" {
  capabilities = ["read"]
}

    Secrets Engine バージョン 2 を使用している場合は、次の権限が必要です。

    path "<your_mount_path>/data/<additional_subpath>" {
  capabilities = ["read"]
}

/*
Datadog needs access to mount information to check the Secrets Engine version
number. If access isn't granted, version 1 is assumed.
*/
path "sys/mounts" {
  capabilities = ["read"]
}

    1. vault policy write <policy_name> <path_to_*.hcl_file> を実行します。

    2. Vault の認証方法を選択します。AWS インスタンスプロファイルメソッドを使用する場合は、vault auth enable aws を実行します。

    AWS インスタンスプロファイルの手順

    AWS に接続されたマシンから HashiCorp Vault を実行している場合、Datadog では インスタンスプロファイルメソッド を使用して認証することを推奨しています。

    セットアップが完了したら、認証専用の Vault ポリシー を記述します。

    構成例

    次の例では、HashiCorp Vault のシークレットパスプレフィックスが /Datadog/Production であり、パラメーターキーが apikey であるとします。

    /DatadogAgent/Production/apikey: (SecureString) "<your_api_key>"

    次の例では、AWS を利用して認証を行い、HashiCorp Vault から API キーの値を取得します。

    # datadog.yaml
api_key: "ENC[/Datadog/Production;apikey]"

secret_backend_type: hashicorp.vault
secret_backend_config:
  vault_address: http://myvaultaddress.net
  vault_session:
    vault_auth_type: aws
    vault_aws_role: Name-of-IAM-role-attached-to-machine
    aws_region: us-east-1 // this field is optional, and will default to us-east-1 if not set

    Agent バージョン 7.75 以上で利用可能

    次の Kubernetes サービスがサポートされています。

    secret_backend_type 値サービス
    k8s.secretsKubernetes Secrets
    前提条件

    Kubernetes Secrets バックエンドには次のものが必要です。

    • ServiceAccount の資格情報: デフォルトでは、自動的にマウントされた ServiceAccount トークンを使用します (automountServiceAccountToken: true、詳細はKubernetes のドキュメントを参照)。必要に応じてカスタムパスを設定できます。
    • RBAC 権限: Agent の ServiceAccount には、ターゲットネームスペースからシークレットを読み取るための権限が必要です。
    • ネットワークアクセス: Agent Pod は Kubernetes API サーバーに到達できる必要があります。
    RBAC のセットアップ

    シークレットを含む各ネームスペースについて、次の例のように正しいネームスペース名を使用して Role と RoleBinding を作成します。

    # Role: grants permission to read secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: datadog-secret-reader
  namespace: <target namepace> # Namespace with secrets
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]
---
# RoleBinding: grants permission to Agent's ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: datadog-secret-access
  namespace: <target namespace>  # Namespace with secrets
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: datadog-secret-reader
subjects:
- kind: ServiceAccount
  name: <serviceaccount name>  # datadog is typically the default ServiceAccount name
  namespace: datadog  # Where Agent runs
    構成例

      Kubernetes Secrets を使用して、次の設定に基づいて Datadog Agent を設定します。

      # datadog.yaml
secret_backend_type: k8s.secrets

# Reference secrets using namespace/secret-name;key format
api_key: "ENC[secrets-prod/dd-api-key;api_key]"
app_key: "ENC[secrets-prod/dd-api-key;app_key]"

      ENC 表記形式は namespace/secret-name;key です。

      • namespace: シークレットを含む Kubernetes ネームスペース
      • secret-name: シークレットリソースの名前
      • key: シークレットのデータフィールドから抽出する特定のキー

      例: ネームスペース secrets-ns におけるシークレットの指定

      apiVersion: v1
kind: Secret
metadata:
  name: dd-api-key
  namespace: secrets-ns
data:
  api_key: <base64-encoded-value>
  app_key: <base64-encoded-value>

      個々のキーを参照できます。

      api_key: "ENC[secrets-ns/dd-api-key;api_key]"
app_key: "ENC[secrets-ns/dd-api-key;app_key]"

      複数ネームスペースのサポート: 各シークレット参照では異なるネームスペースを指定できます (RBAC はそれぞれに対して設定する必要があります)。

      api_key: "ENC[secrets-ns/dd-keys;api_key]"
db_password: "ENC[secrets-shared/db-creds;password]"

      Helm と一緒に Kubernetes Secrets を使用するように Datadog Agent を設定します。

      # values.yaml
datadog:
  apiKey: "placeholder-will-be-overridden"

  env:
  - name: DD_SECRET_BACKEND_TYPE
    value: "k8s.secrets"
  - name: DD_API_KEY
    value: "ENC[secrets-ns/dd-api-key;api_key]"

      注: シークレットバックエンドを使用して API キーを解決する際、Helm チャートの検証にはプレースホルダー apiKey が必要です。これは DD_API_KEY 環境変数によりオーバーライドされます。シークレットを含む各ネームスペースに対して手動で RBAC (ロール + RoleBinding) を作成する必要があります。詳細については、RBAC のセットアップセクションを参照してください。

      **あるいは、**Helm チャート v3.171.0 以上および Agent v7.70 以上の場合は、環境変数の代わりにネイティブの datadog.secretBackend.type フィールドを使用できます。

      Datadog Operator と一緒に Kubernetes Secrets を使用するように Datadog Agent を設定します。

      apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: "placeholder-will-be-overridden"

  override:
    nodeAgent:
      env:
      - name: DD_SECRET_BACKEND_TYPE
        value: "k8s.secrets"
      - name: DD_API_KEY
        value: "ENC[secrets-ns/dd-api-key;api_key]"

      注: プレースホルダー API キーでは、シークレットバックエンドを使用して API キーを解決する際に Operator の検証が満たされます。これは DD_API_KEY 環境変数によりオーバーライドされます。シークレットを含む各ネームスペースに対して手動で RBAC (ロール + RoleBinding) を作成する必要があります。詳細については、RBAC のセットアップセクションを参照してください。

      **あるいは、**Datadog Operator v1.25.0 以上および Agent v7.70 以上の場合は、環境変数の代わりにネイティブの spec.global.secretBackend.type フィールドを使用できます。

      カスタムパスの設定

      デフォルトの ServiceAccount ベース認証の場所に従ってセットアップが行われない場合は、代わりに token_path と ca_path を指定できます。

        secret_backend_type: k8s.secrets
secret_backend_config:
  token_path: /custom/path/to/token
  ca_path: /custom/path/to/ca.crt

        datadog:
  env:
  - name: DD_SECRET_BACKEND_TYPE
    value: "k8s.secrets"
  - name: DD_SECRET_BACKEND_CONFIG
    value: '{"token_path":"/custom/path/to/token","ca_path":"/custom/path/to/ca.crt"}'

        **あるいは、**Helm チャート v3.171.0 以上の場合は、datadog.secretBackend.type: "k8s.secrets" および datadog.secretBackend.config を token_path および ca_path キーを指定して使用できます。

        override:
  nodeAgent:
    env:
    - name: DD_SECRET_BACKEND_TYPE
      value: "k8s.secrets"
    - name: DD_SECRET_BACKEND_CONFIG
      value: '{"token_path":"/custom/path/to/token","ca_path":"/custom/path/to/ca.crt"}'

        **あるいは、**Datadog Operator v1.25.0 以上の場合は、spec.global.secretBackend.type: "k8s.secrets" および spec.global.secretBackend.config を token_path および ca_path キーを指定して使用できます。

        カスタム API サーバーの設定

        セットアップでデフォルトの KUBERNETES_SERVICE_HOST および KUBERNETES_SERVICE_PORT 環境変数が公開されない場合、Kubernetes REST API とのやりとりのために api_server の URL を指定できます。

          secret_backend_type: k8s.secrets
secret_backend_config:
  api_server: https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}

          datadog:
  env:
  - name: DD_SECRET_BACKEND_TYPE
    value: "k8s.secrets"
  - name: DD_SECRET_BACKEND_CONFIG
    value: '{"api_server":"https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}"}'

          **あるいは、**Helm チャート v3.171.0 以上の場合は、datadog.secretBackend.type: "k8s.secrets" および datadog.secretBackend.config を api_server キーを指定して使用できます。

          override:
  nodeAgent:
    env:
    - name: DD_SECRET_BACKEND_TYPE
      value: "k8s.secrets"
    - name: DD_SECRET_BACKEND_CONFIG
      value: '{"api_server":"https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}"}'

          **あるいは、**Datadog Operator v1.25.0 以上の場合は、spec.global.secretBackend.type: "k8s.secrets" および spec.global.secretBackend.config を api_server キーを指定して使用できます。

          Agent バージョン 7.75 以上で利用可能

          次の Docker サービスがサポートされています。

          secret_backend_type 値サービス
          docker.secretsDocker Secrets
          前提条件

          Docker Secrets バックエンドでは、Docker Swarm のシークレット と Docker Compose のシークレット の両方がサポートされています。デフォルトでは、Swarm と Compose の両方が、コンテナ内のシークレットをファイルとして /run/secrets (Linux) または C:\ProgramData\Docker\secrets (Windows) に自動的にマウントします。

          注: Compose シークレットは、ファイルベース (ローカルファイルを指す) または外部 (既存の Swarm シークレットを参照) とすることができます。

          構成例

          Docker Secrets を使用して、次の設定に基づいて Datadog Agent を設定します。

          # datadog.yaml
secret_backend_type: docker.secrets

# Reference secrets using the secret name (filename in /run/secrets)
api_key: "ENC[dd_api_key]"

          ENC 表記形式はシークレット名で、/run/secrets/ 内のファイル名に対応します:

          • ENC[api_key] は /run/secrets/api_key (Linux) または C:\ProgramData\Docker\secrets\api_key (Windows) から読み取ります。

          カスタムシークレットのパス: シークレットを異なる場所にマウントするように Docker Swarm または Compose が設定されている場合は、次のように指定できます。

          secret_backend_type: docker.secrets
secret_backend_config:
  secrets_path: /custom/secrets/path
          Docker Swarm の例

          Docker Swarm シークレットを 作成 して使用します。

          # Create the secret
echo "<api_key_value>" | docker secret create dd_api_key -

# Deploy Agent with secret mounted
docker service create \
  --name datadog-agent \
  --secret dd_api_key \
  --env DD_API_KEY="ENC[dd_api_key]" \
  --env DD_SECRET_BACKEND_TYPE="docker.secrets" \
  --env DD_SITE="datadoghq.com" \
  --env DD_HOSTNAME="dd-agent" \
  registry.datadoghq.com/agent:latest

          シークレット dd_api_key は /run/secrets/dd_api_key に自動的にマウントされ、Agent は docker.secrets バックエンドを使用してそれを読み取ります。

          Docker Compose の例

          ファイルベースのシークレットを使用して docker-compose.yml を 作成 します。

          version: '3.8'

services:
  datadog:
    image: registry.datadoghq.com/agent:latest
    environment:
      - DD_API_KEY=ENC[dd_api_key]
      - DD_SECRET_BACKEND_TYPE=docker.secrets
      - DD_SITE=datadoghq.com
      - DD_HOSTNAME=dd-agent
    secrets:
      - dd_api_key

secrets:
  dd_api_key:
    file: ./secrets/api_key.txt

          シークレットファイル ./secrets/api_key.txt はコンテナ内の /run/secrets/dd_api_key にマウントされます。

          secret_backend_type 値ファイルサービス
          file.jsonJSON
          file.yamlYAML
          file.textTEXT
          ファイルのアクセス許可

          ファイルバックエンドには、設定された JSON、YAML、または TEXT ファイルに対する読み取りアクセス許可のみが必要です。これらのアクセス許可を、ローカルの Datadog Agent ユーザー (Linux では dd-agent、Windows では ddagentuser) に付与する必要があります。

            注: JSON の深度は 1 つのレベルのみサポートされています (たとえば、{"key": "value"})。

            構成例

            JSON ファイルを使用してシークレットをローカルに保存できます。

            たとえば、/path/to/secret.json に次の内容を含む JSON ファイルがある場合:

            {
  "datadog_api_key": "your_api_key"
}

            この設定を使用してシークレットを取得できます。

            # datadog.yaml
api_key: "ENC[datadog_api_key]"

secret_backend_type: file.json
secret_backend_config:
  file_path: /path/to/secret.json

            注: YAML の深度は 1 つのレベルのみサポートされています (たとえば、key: value)。

            構成例

            YAML ファイルを使用してシークレットをローカルに保存できます。

            たとえば、/path/to/secret.yaml 内の YAML ファイルに次の内容が記述されている場合:

            datadog_api_key: your api key

            次の設定を使用してここからシークレットを取得できます。

            # datadog.yaml
api_key: "ENC[datadog_api_key]"
secret_backend_type: file.yaml
secret_backend_config:
  file_path: /path/to/secret.yaml

            Agent バージョン 7.75 以上で利用可能

            注: 各シークレットはそれぞれ個別のテキストファイルに保存する必要があります。

            構成例

            個別のテキストファイルを使用して、シークレットをローカルに保存できます。

            たとえば、/path/to/secrets/ にあるテキストファイルを使用する場合:

            /path/to/secrets/dd_api_key には次の項目が含まれています。

            your_api_key_value

            /path/to/secrets/dd_app_key には次の項目が含まれています。

            your_app_key_value

            この設定を使用して、そこからシークレットを取得できます。

            # datadog.yaml
api_key: "ENC[dd_api_key]"
app_key: "ENC[dd_app_key]"

secret_backend_type: file.text
secret_backend_config:
  secrets_path: /path/to/secrets
            パスのセキュリティ:
            • : ENC[] の相対パスは、secrets_path に対して相対的に解決されます (例: ENC[dd_api_key] と secret_path: /path/to/secrets は /path/to/secrets/dd_api_key に解決されます)。
            • ENC[] の絶対パスは secrets_path 内になければなりません (例: ENC[/path/to/secrets/dd_api_key] と secret_path: /path/to/secrets は有効です)。
            • : パストラバーサルの試み (例: ENC[../etc/passwd]) はブロックされ、「許可されたディレクトリ外のパス」として失敗します。

            注: 一部のツールでは、シークレットをファイルにエクスポートする際に自動的に改行が追加されます。対処方法について詳しくは、末尾の改行を削除するを参照してください。

            オプション 2: Kubernetes と Docker 用の組み込みスクリプトを使用

            コンテナ化された環境では、Datadog Agent のコンテナイメージには、バージョン v7.32.0 以降で使用できる組み込みスクリプト /readsecret_multiple_providers.sh が含まれています。このスクリプトでは、次の場所からシークレットを読み取ることができます。

            • ファイル: ENC[file@/path/to/file] を使用
            • Kubernetes Secrets: ENC[k8s_secret@namespace/secret-name/key] を使用

              Datadog Operator でこの実行ファイルを使用するには、次のように設定します。

              apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    secretBackend:
      command: "/readsecret_multiple_providers.sh"

              Helm チャートでこの実行ファイルを使用するには、次のように設定します。

              datadog:
  [...]
  secretBackend:
    command: "/readsecret_multiple_providers.sh"

              この実行ファイルを使用するには、環境変数 DD_SECRET_BACKEND_COMMAND を次のように設定します。

              DD_SECRET_BACKEND_COMMAND=/readsecret_multiple_providers.sh

              例: マウントされたファイルからの読み取り

              Kubernetes では、エージェントがシークレットを解決するために読み取ることができる Pod 内で シークレットをファイルとして公開する ことができます。

              Kubernetes では、次のようにシークレットをボリュームとしてマウントできます。

                containers:
    - name: agent
      #(...)
      volumeMounts:
        - name: secret-volume
          mountPath: /etc/secret-volume
  #(...)
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret

              そして、シークレットを次のように参照できます。

              password: ENC[file@/etc/secret-volume/password]

              注:

              • シークレットは、マウント先の Pod と同じネームスペースに存在する必要があります。
              • スクリプトからは、機密の /var/run/secrets/kubernetes.io/serviceaccount/token を含むすべてのサブフォルダにアクセスできます。そのため、Datadog では /var/run/secrets の代わりに専用のフォルダを使用することが推奨されています。

              Docker Swarm シークレット は /run/secrets フォルダにマウントされます。たとえば、Docker シークレット db_prod_passsword は Agent コンテナの /run/secrets/db_prod_password にあります。これは、設定で ENC[file@/run/secrets/db_prod_password] として参照されます。

              例: ネームスペースをまたいで Kubernetes シークレットを読み取る

              Agent が異なるネームスペースからシークレットを読み取る必要がある場合は、k8s_secret@ プレフィックスを使用します。たとえば、以下のとおりです。

              password: ENC[k8s_secret@database/database-secret/password]

              Agent のサービスアカウントがシークレットを読み取れるように RBAC を設定します。次のロールは、database-secret ネームスペースで database シークレットに対する読み取りアクセス権を付与します。

                apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    secretBackend:
      command: "/readsecret_multiple_providers.sh"
      roles:
      - namespace: database
        secrets:
        - "database-secret"

                注: また、ロールリスト内の各ネームスペースが、Datadog Operator のデプロイメントで WATCH_NAMESPACE または DD_AGENT_WATCH_NAMESPACE 環境変数に設定されている必要もあります。

                datadog:
  (...)
  secretBackend:
    command: "/readsecret_multiple_providers.sh"
    roles:
      - namespace: database
        secrets:
          - database-secret

                また、RBAC リソースを直接定義することもできます。

                apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: datadog-secret-reader
  namespace: database
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["database-secret"]
    verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: datadog-read-secrets
  namespace: database
subjects:
  - kind: ServiceAccount
    name: datadog-agent
    apiGroup: ""
    namespace: default
roleRef:
  kind: Role
  name: datadog-secret-reader
  apiGroup: ""

                この Role は、Namespace: database で Secret: database-secret に対するアクセス権を付与します。RoleBinding は、Namespace: default で ServiceAccount: datadog-agent に対するこのアクセス許可をリンクします。これは、デプロイされたリソースに関して手動でクラスターに追加する必要があります。

                オプション 3: カスタム実行ファイルの作成

                シークレットを取得するために、Agent ではユーザーが提供した外部の実行ファイルを使用します。実行ファイルは、新しいシークレットが検出され、Agent のライフサイクル期間中キャッシュされたときに使用されます。シークレットを更新またはローテーションする必要がある場合は、Agent を再起動してリロードする必要があります。

                これにより、任意のシークレット管理ソリューションを使用でき、Agent がシークレットにアクセスする方法を完全に制御できます。

                Agent では、解決すべきシークレットハンドルのリストを含む JSON ペイロードが、標準入力経由でこの実行ファイルに送信されます。次に、実行ファイルにより各シークレットが取得され、標準出力を通じてそれらが JSON 形式で返されます。

                以下の例に、Agent により STDIN で実行ファイルに送信される内容を示します。

                {
  "version": "1.0",
  "secrets": ["secret1", "secret2"]
}
                • version (文字列): フォーマットバージョンです。
                • secrets(文字列のリスト): 各文字列はシークレットが取得するハンドルです。

                実行ファイルは、以下の STDOUT 出力を通じて応答します。

                {
  "secret1": {"value": "decrypted_value", "error": null},
  "secret2": {"value": null, "error": "could not fetch the secret"}
}
                • value (文字列): 設定で使用されるシークレットの値。エラーの場合、これは null になる可能性があります。
                • error(文字列): エラーメッセージまたは null です。

                (非ゼロの終了コードまたは非 null のエラーが返され) シークレットの解決に失敗した場合、関連する設定は Agent によって無視されます。

                機密情報は stderr に出力しないでください。バイナリが 0 以外のステータスコードで終了した場合、Agent はトラブルシューティングのために実行ファイルの標準エラー出力をログに記録します。

                任意の言語を使用して、独自のシークレット取得の実行ファイルを構築することもできます。唯一の要件は、前述の入力/出力形式に従うことです。

                ダミーのシークレットを返す Go の例を次に示します。

                package main

import (
  "encoding/json"
  "fmt"
  "io/ioutil"
  "os"
)

type secretsPayload struct {
  Secrets []string `json:secrets`
  Version int      `json:version`
}

func main() {
  data, err := ioutil.ReadAll(os.Stdin)

  if err != nil {
    fmt.Fprintf(os.Stderr, "Could not read from stdin: %s", err)
    os.Exit(1)
  }
  secrets := secretsPayload{}
  json.Unmarshal(data, &secrets)

  res := map[string]map[string]string{}
  for _, handle := range secrets.Secrets {
    res[handle] = map[string]string{
      "value": "decrypted_" + handle,
    }
  }

  output, err := json.Marshal(res)
  if err != nil {
    fmt.Fprintf(os.Stderr, "could not serialize res: %s", err)
    os.Exit(1)
  }
  fmt.Printf(string(output))
}

                これにより、次の設定が

                instances:
  - server: db_prod
    user: ENC[db_prod_user]
    password: ENC[db_prod_password]

                メモリ内で次のように変換されます。

                instances:
  - server: db_prod
    user: decrypted_db_prod_user
    password: decrypted_db_prod_password

                バイナリを使用してシークレットを解決するように Agent を設定するには、次のように追加します。

                secret_backend_command: /path/to/binary

                Agent のセキュリティ要件

                Agent は提供された実行ファイルをサブプロセスとして実行します。実行パターンは Linux と Windows で異なります。

                  Linux では、実行ファイルは次の条件を満たす必要があります。

                  • Agent を実行しているのと同じユーザーに属していること (デフォルトでは dd-agent、またはコンテナ内の root)。
                  • group または other の権限がないこと。
                  • 所有者に対して少なくとも 実行権限があること。

                  Windows では、実行ファイルは次の条件を満たす必要があります。

                  • ddagentuser (Agent の実行に使用するユーザー) に対する読み取りまたは実行権限があること。
                  • Administrators グループ、ビルトインローカルシステムアカウント、または Agent ユーザーコンテキスト (デフォルトでは ddagentuser) 以外のユーザーまたはグループの権限がないこと。
                  • 有効な Win32 アプリケーションであり、Agent で実行できること (たとえば、PowerShell または Python スクリプトは機能しません)。

                  注: 実行ファイルは、Agent と同じ環境変数を共有します。

                  実行時のシークレットのリフレッシュ

                  Agent v7.67 以降、再起動しなくても、解決されたシークレットがリフレッシュされるように Agent を設定できます。

                  リフレッシュ間隔を設定します。

                  secret_refresh_interval: 3600  # refresh every hour

                  または、リフレッシュを手動でトリガーします。

                  datadog-agent secret refresh

                  API/APP キーのリフレッシュ

                  シークレットとして取得された API/APP キーでは、実行時リフレッシュがサポートされています。

                  これを有効にするには、datadog.yaml で secret_refresh_interval (秒単位) を設定します。

                  api_key: ENC[<secret_handle>]

secret_refresh_interval: 3600  # refresh every hour

                  デフォルトでは、Agent は初期リフレッシュを secret_refresh_interval ウィンドウ内でランダム化して、 複数の Agent が同時にリフレッシュされるのを防ぎます。キーは起動時に解決され、その後、最初の間隔内で一度リフレッシュされます。 以降、間隔ごとにリフレッシュされます。

                  ダウンタイムを防ぐため、全 Agent で更新済みのキーの取得が完了するまで待ってから、古いキーを無効にしてください。キーの使用状況の追跡は、 フリート管理ページで行うことができます。

                  この動作を無効にするには、次のように設定します。

                  secret_refresh_scatter: false

                  Autodiscovery チェックのシークレットのリフレッシュ

                  Agent v7.76 以降、スケジュールされた Autodiscovery チェックでは、テンプレートが ENC[] 構文を使用している場合、実行時にシークレットをリフレッシュできます。

                  labels:
  tags.datadoghq.com/redis.env: "prod"
  tags.datadoghq.com/redis.service: "my-redis"
  tags.datadoghq.com/redis.version: "6.0.3"
annotations:
  ad.datadoghq.com/redis.checks: |
    {
      "redisdb": {
        "init_config": {},
        "instances": [
          {
            "host": "%%host%%",
            "port":"6379",
            "password":"ENC[<secret_handle>]"
          }
        ]
      }
    }

                  その後、Agent では、secret_refresh_interval に設定された間隔で、または datadog-agent secret refresh を使用して手動で、シークレットのリフレッシュをトリガーできます。

                  API キーの失敗時または無効化時のシークレットの自動リフレッシュ

                  Agent バージョン v7.74 以降、Agent では無効な API キーを検出した際にシークレットを自動的にリフレッシュできます。これは、Agent が Datadog から「403 Forbidden」の応答を受け取った場合、または定期的なヘルスチェックで無効または期限切れの API キーが検出された場合に発生します。

                  この機能を有効にするには、datadog.yaml ファイルで secret_refresh_on_api_key_failure_interval を分単位の間隔に設定します。無効にするには、0 に設定します (デフォルト)。

                  この間隔は、無効な API キーが検出された際に、シークレット管理ソリューションへのスパムを防ぐために 2 回のリフレッシュの間に設けられる最小時間です。

                  api_key: ENC[<secret_handle>]

secret_refresh_on_api_key_failure_interval: 10

                  この設定は secret_refresh_interval と互換性があります。

                  DDOT コレクターリフレッシュの有効化

                  DDOT コレクター を使用していて、API/APP リフレッシュを有効にしたい場合は、次の追加設定を datadog.yaml ファイルに追加する必要があります。

                  agent_ipc:
  port: 5051
  config_refresh_interval: 3600

                  これにより、シークレットがリフレッシュされた後、DDOT コレクターと Agent の同期が維持されます。Agent で設定状態が定期的に確認されるのと同様の方法で、DDOT コレクターではこの設定を使用して Agent で更新された値を定期的にチェックします。

                  トラブルシューティング

                  検出されたシークレットのリスト

                  Agent CLI の secret コマンドでは、セットアップに関連するエラーが表示されます。たとえば、実行ファイルの権限が不正確な場合です。また、検出されたすべてのハンドルとその場所がリストされます。

                  Linux では、コマンドにより、実行ファイルのファイルモード、所有者、およびグループが出力されます。Windows では、ACL 権限がリストされます。

                    Linux の例

                    datadog-agent secret
=== Checking executable rights ===
Executable path: /path/to/you/executable
Check Rights: OK, the executable has the correct rights

Rights Detail:
file mode: 100700
Owner username: dd-agent
Group name: dd-agent

=== Secrets stats ===
Number of secrets decrypted: 3
Secrets handle decrypted:
- api_key: from datadog.yaml
- db_prod_user: from postgres.yaml
- db_prod_password: from postgres.yaml

                    Windows の例 (管理者の PowerShell から)

                    PS C:\> & "$env:ProgramFiles\Datadog\Datadog Agent\bin\agent.exe" secret
=== Checking executable rights ===
Executable path: C:\path\to\you\executable.exe
Check Rights: OK, the executable has the correct rights

Rights Detail:
Acl list:
stdout:

Path   : Microsoft.PowerShell.Core\FileSystem::C:\path\to\you\executable.exe
Owner  : BUILTIN\Administrators
Group  : WIN-ITODMBAT8RG\None
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         WIN-ITODMBAT8RG\ddagentuser Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : O:BAG:S-1-5-21-2685101404-2783901971-939297808-513D:PAI(A;;FA;;;SY)(A;;FA;;;BA)(A;;0x1200
         a9;;;S-1-5-21-2685101404-2783901971-939297808-1001)

=== Secrets stats ===
Number of secrets decrypted: 3
Secrets handle decrypted:
- api_key: from datadog.yaml
- db_prod_user: from sqlserver.yaml
- db_prod_password: from sqlserver.yaml

                    シークレットが挿入された後の設定の表示

                    チェックの設定がどのように解決されるかをすばやく確認するには、configcheck コマンドを使用します。

                    sudo -u dd-agent -- datadog-agent configcheck

=== a check ===
Source: File Configuration Provider
Instance 1:
host: <decrypted_host>
port: <decrypted_port>
password: <obfuscated_password>
~
===

=== another check ===
Source: File Configuration Provider
Instance 1:
host: <decrypted_host2>
port: <decrypted_port2>
password: <obfuscated_password2>
~
===

                    注: Agent は、構成ファイルの変更を取得するために 再起動 する必要があります。

                    secret_backend_command のデバッグ

                    Agent の外部でテストまたはデバッグするには、Agent の実行方法を模倣します。

                      Linux

                      sudo -u dd-agent bash -c "echo '{\"version\": \"1.0\", \"secrets\": [\"secret1\", \"secret2\"]}' | /path/to/the/secret_backend_command"

                      Datadog Agent をインストールすると、dd-agent ユーザーが作成されます。

                      次のエラーは、セットアップで何かが欠落していることを示しています。

                      1. 必要でないグループまたはユーザーが実行ファイルに対して権限を持っている場合、次のようなエラーがログに記録されます。

                        error while decrypting secrets in an instance: Invalid executable 'C:\decrypt.exe': other users/groups than LOCAL_SYSTEM, Administrators or ddagentuser have rights on it

                      2. ddagentuser にファイルに対する読み取りおよび実行権限がない場合、同様のエラーがログに記録されます。

                        error while decrypting secrets in an instance: could not query ACLs for C:\decrypt.exe

                      3. 実行ファイルは有効な Win32 アプリケーションである必要があります。そうでない場合、次のエラーがログに記録されます。

                        error while running 'C:\decrypt.py': fork/exec C:\decrypt.py: %1 is not a valid Win32 application.

                      Datadog には、実行ファイルに正しい権限を設定するのに役立つ Powershell スクリプト があります。その使用方法の例を次に示します。

                      .\Set-SecretPermissions.ps1 -SecretBinaryPath C:\secrets\decrypt_secrets.exe
ddagentuser SID: S-1-5-21-3139760116-144564943-2741514060-1076
=== Checking executable permissions ===
Executable path: C:\secrets\decrypt_secrets.exe
Executable permissions: OK, the executable has the correct permissions

Permissions Detail:

stdout:
Path   : Microsoft.PowerShell.Core\FileSystem::C:\secrets\decrypt_secrets.exe
Owner  : BUILTIN\Administrators
Group  : BUILTIN\Administrators
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         DESKTOP-V03BB2P\ddagentuser Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : O:BAG:BAD:PAI(A;;FA;;;SY)(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-3139760116-144564943-2741514
         060-1076)
stderr:


=== Secrets stats ===
Number of secrets resolved: 0
Secrets handle resolved:
                      実行ファイルのテスト

                      実行ファイルは、シークレットの取得時に Agent によって実行されます。Datadog Agent は ddagentuser を使用して実行されます。このユーザーには特定の権限はありませんが、Performance Monitor Users グループの一部です。このユーザーのパスワードはインストール時にランダムに生成され、どこにも保存されません。

                      そのため、実行ファイルはデフォルトのユーザーまたは開発ユーザーで動作する可能性がありますが、ddagentuser の権限は制限が強いため、Agent によって実行されるときは動作しません。

                      Agent と同じ条件で実行ファイルをテストするには、開発用マシンの ddagentuser のパスワードを更新してください。この方法で、ddagentuser として認証し、Agent と同じコンテキストで実行ファイルを実行できます。

                      これを行うには、次の手順を実行します。

                      1. Local Security Policy の Local Policies/User Rights Assignement/Deny Log on locally リストから ddagentuser を削除します。
                      2. ddagentuser に新しいパスワードを設定します (インストール時に生成されたパスワードはどこにも保存されないため)。PowerShell で、次を実行します。
                        $user = [ADSI]"WinNT://./ddagentuser";
$user.SetPassword("a_new_password")
                      3. サービスコントロールマネージャーの DatadogAgent サービスで使用されるパスワードを更新します。PowerShell で、次を実行します。
                        sc.exe config DatadogAgent password= "a_new_password"

                      これで、ddagentuser としてログインして実行ファイルをテストできます。Datadog の PowerShell スクリプト は、実行ファイルを 別のユーザーとしてテストするのに役立ちます。ユーザーのコンテキストを切り替え、Agent での実行ファイルの実行方法を模倣します。

                      その使用方法の例を次に示します。

                      .\secrets_tester.ps1 -user ddagentuser -password a_new_password -executable C:\path\to\your\executable.exe -payload '{"version": "1.0", "secrets": ["secret_ID_1", "secret_ID_2"]}'
Creating new Process with C:\path\to\your\executable.exe
Waiting a second for the process to be up and running
Writing the payload to Stdin
Waiting a second so the process can fetch the secrets
stdout:
{"secret_ID_1":{"value":"secret1"},"secret_ID_2":{"value":"secret2"}}
stderr: None
exit code:
0

                      Agent による起動の拒否

                      Agent の起動時の最初の処理は、datadog.yaml をロードし、その中のシークレットを復号化することです。これは、ログのセットアップの前に行われます。そのため、Windows のようなプラットフォームでは、datadog.yaml のロード時に発生するエラーがログに書き込まれず、stderr に書き込まれます。これは、シークレットのために Agent に渡された実行ファイルがエラーを返すときに発生する可能性があります。

                      datadog.yaml にシークレットがあり、Agent により起動を拒否された場合、次のことを行ってください。

                      • stderr を表示できるように、手動での Agent の起動を試みます。
                      • datadog.yaml からシークレットを削除し、最初にチェック構成ファイルでシークレットをテストします。

                      Kubernetes の権限のテスト

                      Kubernetes から直接シークレットを読み込む場合、kubectl auth コマンドで権限をダブルチェックすることができます。一般的な形は次のとおりです。

                      kubectl auth can-i get secret/<SECRET_NAME> -n <SECRET_NAMESPACE> --as system:serviceaccount:<AGENT_NAMESPACE>:<AGENT_SERVICE_ACCOUNT>

                      先ほどの Kubernetes Secrets の例で、シークレット Secret:database-secret が Namespace: database に存在し、サービスアカウント ServiceAccount:datadog-agent が Namespace: default に存在していると考えてみましょう。

                      この場合、次のコマンドを使用します。

                      kubectl auth can-i get secret/database-secret -n database --as system:serviceaccount:default:datadog-agent

                      このコマンドは、Agent がこのシークレットを閲覧するための権限が有効であるかどうかを返します。

                      行末の改行を削除する

                      一部のシークレット管理ツールでは、ファイルを通じてシークレットをエクスポートする際に自動的に改行を追加します。これらの改行は、特にコンテナ化された環境で、datadog.yaml 構成ファイル に secret_backend_remove_trailing_line_break: true を設定するか、環境変数 DD_SECRET_BACKEND_REMOVE_TRAILING_LINE_BREAK を使用して削除できます。

                      シークレットハンドルにおける Autodiscovery 変数

                      シークレットハンドルで Autodiscovery 変数を使用することもできます。Agent では、シークレットを解決する前にこれらの変数が解決されます。たとえば、以下のとおりです。

                      instances:
  - server: %%host%%
    user: ENC[db_prod_user_%%host%%]
    password: ENC[db_prod_password_%%host%%]

                      参考資料

                      お役に立つドキュメント、リンクや記事:

                      Autodiscoveryよくあるご質問 more more