Resumen

El Agente de Datadog te ayuda a gestionar tus secretos de manera segura integrándose con las siguientes soluciones de gestión de secretos:

• AWS Secrets Manager
• AWS SSM
• Azure KeyVault
• GCP Secret Manager
• HashiCorp Vault
• Kubernetes Secrets
• Docker Secrets
• Texto de archivo
• Archivo JSON
• Archivo YAML

En lugar de codificar valores sensibles como claves de API o contraseñas en texto plano dentro de archivos de configuración, el Agente puede recuperarlos dinámicamente en tiempo de ejecución. Para hacer referencia a un secreto en tu configuración, utiliza la notación ENC[<secret_id>]. El secreto se recupera y se carga en memoria, pero nunca se escribe en disco ni se envía al backend de Datadog.

Nota: No puedes usar la sintaxis ENC[] en configuraciones secret_* como secret_backend_command.

Opciones para recuperar secretos

Opción 1: Usar soporte nativo del Agente para recuperar secretos

Nota: A partir de la versión 7.76 del Agente y en adelante, la gestión nativa de secretos está disponible para Agentes habilitados para FIPS.

A partir de la versión 7.70 del Agente, el Agente de Datadog soporta nativamente varias soluciones de gestión de secretos. Se han introducido dos nuevas configuraciones en datadog.yaml: secret_backend_type y secret_backend_config.

secret_backend_type se utiliza para especificar qué solución de gestión de secretos usar, y secret_backend_config contiene configuración adicional relevante para esa solución.

# datadog.yaml

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

Nota: Si estás ejecutando Datadog en un entorno contenedorizado, el Agente de clúster requiere el Agente 7.77 o posterior para soportar la obtención nativa de secretos. Para versiones anteriores, utiliza Opción 2 o Opción 3 en su lugar.

Instrucciones de configuración más específicas dependen del tipo de backend utilizado. Consulta la sección apropiada a continuación para obtener más información:

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

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

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

api_key: ENC[My-Secrets;prodApiKey]

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

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>

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>

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

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

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

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

# datadog.yaml

api_key: "ENC[secretKeyNameInKeyVault]"

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

# 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>

{
  "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>

path "<your mount path>/<additional subpath>" {
  capabilities = ["read"]
}

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

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

# 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

# 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

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

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

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

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

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

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

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

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

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.yaml
secret_backend_type: docker.secrets

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

secret_backend_type: docker.secrets
secret_backend_config:
  secrets_path: /custom/secrets/path

# 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

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

{
  "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

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

your_api_key_value

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

Opción 2: Usando el script incorporado para Kubernetes y Docker

Para entornos en contenedores, las imágenes de contenedor del Agente de Datadog incluyen un script incorporado /readsecret_multiple_providers.sh a partir de la versión v7.32.0. Este script admite la lectura de secretos desde:

• Archivos: usando ENC[file@/path/to/file]
• Secretos de Kubernetes: usando ENC[k8s_secret@namespace/secret-name/key]

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

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

DD_SECRET_BACKEND_COMMAND=/readsecret_multiple_providers.sh

Ejemplo: Leyendo desde archivos montados

Kubernetes admite exponer Secrets como archivos dentro de un pod que el Agente puede leer para resolver secretos.

En Kubernetes, puedes montar un Secret como un volumen de esta manera:

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

Luego puedes hacer referencia al secreto de esta manera:

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

Notas:

• El Secret debe existir en el mismo namespace que el pod en el que se está montando.
• El script puede acceder a todas las subcarpetas, incluyendo el /var/run/secrets/kubernetes.io/serviceaccount/token sensible. Por lo tanto, Datadog recomienda usar una carpeta dedicada en lugar de /var/run/secrets.

Los secretos de Docker Swarm se montan en la carpeta /run/secrets. Por ejemplo, el secreto de Docker db_prod_passsword se encuentra en /run/secrets/db_prod_password en el contenedor del Agente. Esto se referenciaría en la configuración con ENC[file@/run/secrets/db_prod_password].

Ejemplo: Leyendo un secreto de Kubernetes a través de namespaces

Si deseas que el Agente lea un Secret de un namespace diferente, usa el prefijo k8s_secret@. Por ejemplo:

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

Configura RBAC para permitir que la Cuenta de Servicio del Agente lea el Secret. El siguiente Rol otorga acceso de lectura al Secret database-secret en el namespace 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:
  (...)
  secretBackend:
    command: "/readsecret_multiple_providers.sh"
    roles:
      - namespace: database
        secrets:
          - database-secret

Alternativamente, puedes definir recursos RBAC directamente:

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: ""

Esto Role da acceso al Secret: database-secret en el Namespace: database. El RoleBinding vincula este permiso al ServiceAccount: datadog-agent en el Namespace: default. Esto necesita ser agregado manualmente a su clúster con respecto a los recursos desplegados.

Opción 3: Creando un ejecutable personalizado

Para recuperar secretos, el Agente utiliza un ejecutable externo que tú proporcionas. El ejecutable se utiliza cuando se descubren nuevos secretos y se almacenan en caché durante el ciclo de vida del Agente. Si necesita actualizar o rotar un secreto, debe reiniciar el Agente para recargarlo.

Esto le permite usar cualquier solución de gestión de secretos y le da control total sobre cómo el Agente accede a los secretos.

El Agente envía a este ejecutable una carga útil JSON a través de la entrada estándar que contiene una lista de identificadores de secretos por resolver. Luego, su ejecutable obtiene cada secreto y los devuelve en un formato JSON a través de la salida estándar.

El siguiente ejemplo muestra lo que el Agente envía a su ejecutable en STDIN:

{
  "version": "1.0",
  "secrets": ["secret1", "secret2"]
}

• version (cadena): La versión del formato.
• secrets (lista de cadenas): Cada cadena es un identificador para un secreto a recuperar.

El ejecutable responde a través de la siguiente salida STDOUT:

{
  "secret1": {"value": "decrypted_value", "error": null},
  "secret2": {"value": null, "error": "could not fetch the secret"}
}

• value (cadena): El valor del secreto que se utilizará en las configuraciones. Esto puede ser null en caso de un error.
• error (cadena): Un mensaje de error o null.

Si un secreto no se puede resolver (ya sea devolviendo un código de salida distinto de cero o un error no nulo), la configuración relacionada es ignorada por el Agente.

Nunca divulgue información sensible en stderr. Si el binario sale con un código de estado diferente a 0, el Agente registra la salida de error estándar de su ejecutable para la solución de problemas.

También puede construir su propio ejecutable de recuperación de secretos utilizando cualquier lenguaje. El único requisito es que siga el formato de entrada/salida descrito anteriormente.

Aquí hay un ejemplo en Go que devuelve secretos ficticios:

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))
}

Esto transforma su configuración:

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

En lo siguiente en memoria:

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

Puede configurar el Agente para usar el binario para resolver secretos agregando lo siguiente:

secret_backend_command: /path/to/binary

Requisitos de seguridad del Agente

El Agente ejecuta el ejecutable proporcionado como un subproceso. Los patrones de ejecución difieren en Linux y Windows.

Nota: Su ejecutable comparte las mismas variables de entorno que el Agente.

Actualizando secretos en tiempo de ejecución

A partir de la versión 7.67 del Agente, puede configurar el Agente para actualizar secretos resueltos sin requerir un reinicio.

Establezca un intervalo de actualización:

secret_refresh_interval: 3600  # refresh every hour

O, active una actualización manualmente:

datadog-agent secret refresh

Actualización de clave API/APP

Las claves API/APP extraídas como secretos admiten actualización en tiempo de ejecución.

Puede habilitar esto configurando secret_refresh_interval (en segundos) en datadog.yaml:

api_key: ENC[<secret_handle>]

secret_refresh_interval: 3600  # refresh every hour

Por defecto, el Agente aleatoriza la actualización inicial dentro de la ventana de secret_refresh_interval para evitar que una flota de Agentes se actualicen simultáneamente. La clave se resuelve al inicio, luego se actualiza una vez dentro del primer intervalo y cada intervalo posterior.

Para evitar tiempo de inactividad, invalide las claves antiguas solo después de que toda su flota haya extraído las claves actualizadas. Puede rastrear el uso de claves en la página Gestión de Flota.

Puede desactivar este comportamiento configurando:

secret_refresh_scatter: false

Actualización de secretos de la verificación de Autodiscovery

A partir de la versión 7.76 del Agente, las verificaciones programadas de Autodiscovery pueden actualizar secretos en tiempo de ejecución si la plantilla utiliza la sintaxis 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>]"
          }
        ]
      }
    }

El Agente puede entonces activar la actualización de secretos ya sea en el intervalo establecido en secret_refresh_interval o manualmente con datadog-agent secret refresh.

La actualización automática de secretos se realiza al fallar o invalidar la clave de API

A partir de la versión v7.74 del Agente, este puede actualizar automáticamente los secretos cuando detecta una clave de API inválida. Esto ocurre cuando el Agente recibe una respuesta 403 Prohibido de Datadog o cuando la verificación de salud periódica detecta una clave de API inválida o caducada.

Para habilitar esta función, establece secret_refresh_on_api_key_failure_interval en un intervalo en minutos en tu archivo datadog.yaml. Establece en 0 para deshabilitar (predeterminado).

Este intervalo es el tiempo mínimo entre 2 actualizaciones para evitar saturar tu solución de gestión de secretos cuando se detecta una clave de API inválida.

api_key: ENC[<secret_handle>]

secret_refresh_on_api_key_failure_interval: 10

Esta configuración es compatible con secret_refresh_interval.

Habilitando la actualización del colector DDOT

Si estás utilizando el colector DDOT y deseas habilitar la actualización de API/APP, debes agregar la siguiente configuración adicional a tu archivo datadog.yaml:

agent_ipc:
  port: 5051
  config_refresh_interval: 3600

Esto asegura que el colector DDOT se mantenga sincronizado con el Agente después de que se actualicen los secretos. De manera similar a cómo el Agente verifica periódicamente su estado de configuración, el colector DDOT utiliza esta configuración para verificar regularmente los valores actualizados del Agente.

Resolución de problemas

Listando secretos detectados

El comando secret en la CLI del Agente muestra cualquier error relacionado con tu configuración. Por ejemplo, si los permisos sobre el ejecutable son incorrectos. También lista todos los manejadores encontrados y dónde se encuentran.

En Linux, el comando muestra el modo de archivo, propietario y grupo para el ejecutable. En Windows, se listan los permisos de ACL.

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

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

Viendo configuraciones después de que se inyectaron secretos

Para ver rápidamente cómo se resuelven las configuraciones de la verificación, puedes usar el comando 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>
~
===

Nota: El Agent necesita ser reiniciado para recoger cambios en los archivos de configuración.

Depurando tu comando_secret_backend

Para probar o depurar fuera del Agent, puedes imitar cómo lo ejecuta el Agent:

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

.\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:

.\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