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
• Archivo de Texto
• 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 obtener 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 admite de forma nativa 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 utilizar, 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á ejecutando Datadog en un entorno contenedorizado, el Agente de Clúster requiere el Agente 7.77 o posterior para admitir la obtención nativa de secretos. Para versiones anteriores, usa Opción 2 o Opción 3 en su lugar.

Las instrucciones de configuración más específicas dependen del tipo de backend utilizado. Consulta la sección correspondiente a continuación para 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" \
  datadog/agent:latest

version: '3.8'

services:
  datadog:
    image: datadog/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 Datadog Agent 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 secretos como archivos dentro de un pod que el Agent puede leer para resolver secretos.

En Kubernetes, puede montar un secreto 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

Puede referenciar el secreto de esta manera:

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

Notas:

• El secreto debe existir en el mismo espacio de nombres que el pod en el que se está montando.
• El script puede acceder a todas las subcarpetas, incluyendo el sensible /var/run/secrets/kubernetes.io/serviceaccount/token. 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 Agent. 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 espacios de nombres

Si deseas que el Agent lea un secreto de un espacio de nombres 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 Agent lea el secreto. El siguiente rol otorga acceso de lectura al secreto database-secret en el espacio de nombres 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 de 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: ""

Este Role otorga 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 tu clúster con respecto a tus recursos desplegados.

Opción 3: Creando un ejecutable personalizado

Para recuperar secretos, el Agent 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 Agent. Si necesitas actualizar o rotar un secreto, debes reiniciar el Agent para recargarlo.

Esto te permite utilizar cualquier solución de gestión de secretos y te da control total sobre cómo el Agent accede a los secretos.

El Agent 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 a resolver. Luego, tu 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 Agent envía a tu 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 Agent.

Nunca muestre información sensible en stderr. Si el binario sale con un código de estado diferente a 0, el Agent registra la salida de error estándar de tu ejecutable para solucionar 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 tu 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

Puedes configurar el Agent para usar el binario para resolver secretos añadiendo lo siguiente:

secret_backend_command: /path/to/binary

Requisitos de seguridad del Agent

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

Nota: Tu ejecutable comparte las mismas variables de entorno que el Agent.

Refrescando secretos en tiempo de ejecución

A partir de la versión 7.67 del Agent, puedes configurar el Agent para refrescar secretos resueltos sin necesidad de reiniciar.

Establece un intervalo de refresco:

secret_refresh_interval: 3600  # refresh every hour

O, activa un refresco manualmente:

datadog-agent secret refresh

Refresco de clave de API/APP

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

Puedes 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 Agent aleatoriza el refresco inicial dentro de la ventana de secret_refresh_interval para evitar que una flota de para evitar que todos los Agent se refresquen simultáneamente. La clave se resuelve al inicio, luego se refresca una vez dentro del primer intervalo y cada intervalo posterior.

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

Puedes deshabilitar este comportamiento configurando:

secret_refresh_scatter: false

Refresco de secretos de verificación de Autodiscovery

A partir de la versión 7.76 del Agent, las verificaciones programadas de Autodiscovery pueden refrescar 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 Agent puede entonces activar el refresco de secretos ya sea en el intervalo establecido en secret_refresh_interval o manualmente con datadog-agent secret refresh.

Refresco automático de secretos en caso de fallo/invalidación de clave de API

A partir de la versión 7.74 del Agent, el Agent puede refrescar automáticamente secretos cuando detecta una clave de API inválida. Esto sucede cuando el Agent recibe una respuesta 403 Prohibido de Datadog o cuando la verificación de salud periódica detecta una clave de API inválida o expirada.

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

Este intervalo es la cantidad mínima de tiempo 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 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 permanezca sincronizado con el Agent después de que se actualicen los secretos. De manera similar a cómo el Agent verifica periódicamente su estado de configuración, el colector DDOT utiliza esta configuración para verificar regularmente los valores actualizados del Agent.

Resolución de problemas

Lista de secretos detectados

El comando secret en la CLI del Agent muestra cualquier error relacionado con tu configuración. Por ejemplo, si los derechos 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 derechos 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

Ver configuraciones después de que se inyectaron los 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 Agente necesita ser reiniciado para recoger los cambios en los archivos de configuración.

Depurando tu secret_backend_command

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

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