Aperçu

L’Agent Datadog vous aide à gérer vos secrets de manière sécurisée en s’intégrant aux solutions de gestion des secrets suivantes :

• AWS Secrets Manager
• AWS SSM
• Azure KeyVault
• GCP Secret Manager
• HashiCorp Vault
• Kubernetes Secrets
• Docker Secrets
• Texte de fichier
• Fichier JSON
• Fichier YAML

Au lieu de coder en dur des valeurs sensibles comme des clés API ou des mots de passe en texte clair dans des fichiers de configuration, l’Agent peut les récupérer dynamiquement au moment de l’exécution. Pour référencer un secret dans votre configuration, utilisez la notation ENC[<secret_id>]. Le secret est récupéré et chargé en mémoire mais n’est jamais écrit sur le disque ni envoyé au backend Datadog.

Remarque : Vous ne pouvez pas utiliser la syntaxe ENC[] dans les paramètres secret_* comme secret_backend_command.

Options pour récupérer des secrets

Option 1 : Utiliser le support natif de l’Agent pour récupérer des secrets

Remarque : À partir de la version 7.76 de l’Agent et au-delà, la gestion native des secrets est disponible pour les Agents activés FIPS.

À partir de la version 7.70 de l’Agent, l’Agent Datadog prend en charge nativement plusieurs solutions de gestion des secrets. Deux nouveaux paramètres ont été introduits dans datadog.yaml : secret_backend_type et secret_backend_config.

secret_backend_type est utilisé pour spécifier quelle solution de gestion des secrets utiliser, et secret_backend_config contient une configuration supplémentaire pertinente pour cette solution.

# datadog.yaml

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

Remarque : Si vous exécutez Datadog dans un environnement conteneurisé, le Cluster Agent nécessite l’Agent 7.77 ou une version ultérieure pour prendre en charge la récupération native des secrets. Pour les versions antérieures, utilisez Option 2 ou Option 3 à la place.

Des instructions de configuration plus spécifiques dépendent du type de backend utilisé. Voir la section appropriée ci-dessous pour plus d’informations :

# 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

Option 2 : Utiliser le script intégré pour Kubernetes et Docker

Pour les environnements conteneurisés, les images de conteneur de l’Agent Datadog incluent un script intégré /readsecret_multiple_providers.sh à partir de la version v7.32.0. Ce script prend en charge la lecture des secrets depuis :

• Fichiers : en utilisant ENC[file@/path/to/file]
• Secrets Kubernetes : en utilisant 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

Exemple : Lecture à partir de fichiers montés

Kubernetes prend en charge l’exposition des Secrets en tant que fichiers à l’intérieur d’un pod que l’Agent peut lire pour résoudre les secrets.

Dans Kubernetes, vous pouvez monter un Secret en tant que volume comme ceci :

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

Vous pouvez ensuite référencer le secret comme ceci :

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

Remarques :

• Le Secret doit exister dans le même espace de noms que le pod dans lequel il est monté.
• Le script peut accéder à tous les sous-dossiers, y compris le /var/run/secrets/kubernetes.io/serviceaccount/token sensible. Ainsi, Datadog recommande d’utiliser un dossier dédié au lieu de /var/run/secrets.

Les secrets de Docker swarm sont montés dans le dossier /run/secrets. Par exemple, le secret Docker db_prod_passsword est situé dans /run/secrets/db_prod_password dans le conteneur de l’Agent. Cela serait référencé dans la configuration avec ENC[file@/run/secrets/db_prod_password].

Exemple : Lecture d’un secret Kubernetes à travers les namespaces

Si vous souhaitez que l’Agent lise un Secret d’un namespace différent, utilisez le préfixe k8s_secret@. Exemple :

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

Configurez RBAC pour permettre au compte de service de l’Agent de lire le Secret. Le rôle suivant accorde l’accès en lecture au Secret database-secret dans le 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

Alternativement, vous pouvez définir les ressources RBAC directement :

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

Ce Role donne accès au Secret: database-secret dans le Namespace: database. Le RoleBinding relie cette permission au ServiceAccount: datadog-agent dans le Namespace: default. Cela doit être ajouté manuellement à votre cluster en fonction de vos ressources déployées.

Option 3 : Création d’un exécutable personnalisé

Pour récupérer des secrets, l’Agent utilise un exécutable externe que vous fournissez. L’exécutable est utilisé lorsque de nouveaux secrets sont découverts et sont mis en cache pour le cycle de vie de l’Agent. Si vous devez mettre à jour ou faire pivoter un secret, vous devez redémarrer l’Agent pour le recharger.

Cela vous permet d’utiliser n’importe quelle solution de gestion de secrets et vous donne un contrôle total sur la façon dont l’Agent accède aux secrets.

L’Agent envoie à cet exécutable une charge utile JSON via l’entrée standard contenant une liste de gestionnaires de secrets à résoudre. Ensuite, votre exécutable récupère chaque secret et les renvoie au format JSON via la sortie standard.

L’exemple suivant montre ce que l’Agent envoie à votre exécutable sur STDIN :

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

• version (string) : La version du format.
• secrets (liste de chaînes) : Chaque chaîne est un identifiant pour un secret à récupérer.

L’exécutable répond par la sortie STDOUT suivante :

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

• value (string) : La valeur secrète à utiliser dans les configurations. Cela peut être null en cas d’erreur.
• error (string) : Un message d’erreur ou null.

Si un secret ne peut pas être résolu (soit en retournant un code de sortie non nul, soit une erreur non nulle), la configuration associée est ignorée par l’Agent.

Ne jamais afficher d’informations sensibles sur stderr. Si le binaire se termine avec un code d’état différent de 0, l’Agent enregistre la sortie d’erreur standard de votre exécutable pour le dépannage.

Vous pouvez également créer votre propre exécutable de récupération de secrets en utilisant n’importe quel langage. La seule exigence est qu’il suive le format d’entrée/sortie décrit précédemment.

Voici un exemple en Go qui retourne des secrets fictifs :

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

Cela transforme votre configuration :

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

En ce qui suit en mémoire :

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

Vous pouvez configurer l’Agent pour utiliser le binaire afin de résoudre les secrets en ajoutant ce qui suit :

secret_backend_command: /path/to/binary

Exigences de sécurité de l’Agent

L’Agent exécute l’exécutable fourni en tant que sous-processus. Les modèles d’exécution diffèrent sur Linux et Windows.

Remarque : Votre exécutable partage les mêmes variables d’environnement que l’Agent.

Rafraîchissez les secrets à l’exécution

À partir de la version 7.67 de l’Agent, vous pouvez configurer l’Agent pour rafraîchir les secrets résolus sans nécessiter un redémarrage.

Définir un intervalle de rafraîchissement :

secret_refresh_interval: 3600  # refresh every hour

Ou déclenchez un rafraîchissement manuellement :

datadog-agent secret refresh

Rafraîchissement de la clé API/APP

Les clés API/APP extraites en tant que secrets prennent en charge le rafraîchissement à l’exécution.

Vous pouvez activer cela en définissant secret_refresh_interval (en secondes) dans datadog.yaml :

api_key: ENC[<secret_handle>]

secret_refresh_interval: 3600  # refresh every hour

Par défaut, l’Agent randomise le rafraîchissement initial dans la fenêtre secret_refresh_interval pour éviter qu’une flotte de Les Agents ne se rafraîchissent pas simultanément. La clé est résolue au démarrage, puis rafraîchie une fois dans le premier intervalle et à chaque intervalle par la suite.

Pour éviter les temps d’arrêt, invalidez les anciennes clés uniquement après que votre flotte entière a récupéré les clés mises à jour. Vous pouvez suivre l’utilisation des clés sur la page Gestion de la flotte.

Vous pouvez désactiver ce comportement en définissant :

secret_refresh_scatter: false

Vérification de l’autodécouverte des secrets

À partir de l’Agent v7.76, les vérifications programmées Autodécouverte peuvent actualiser les secrets en temps réel si le modèle utilise la syntaxe 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>]"
          }
        ]
      }
    }

L’Agent peut alors déclencher l’actualisation des secrets soit à l’intervalle défini dans secret_refresh_interval, soit manuellement avec datadog-agent secret refresh.

Actualisation automatique des secrets en cas d’échec / d’invalidation de la clé API

À partir de la version v7.74 de l’Agent, l’Agent peut actualiser automatiquement les secrets lorsqu’il détecte une clé API invalide. Cela se produit lorsque l’Agent reçoit une réponse 403 Interdit de Datadog ou lorsque la vérification de santé périodique détecte une clé API invalide ou expirée.

Pour activer cette fonctionnalité, définissez secret_refresh_on_api_key_failure_interval sur un intervalle en minutes dans votre fichier datadog.yaml. Définissez sur 0 pour désactiver (par défaut).

Cet intervalle est le temps minimum entre 2 actualisations pour éviter de saturer votre solution de gestion des secrets lorsqu’une clé API invalide est détectée.

api_key: ENC[<secret_handle>]

secret_refresh_on_api_key_failure_interval: 10

Ce paramètre est compatible avec secret_refresh_interval.

Activation de l’actualisation du collecteur DDOT

Si vous utilisez le collecteur DDOT et souhaitez activer l’actualisation API/APP, vous devez ajouter la configuration supplémentaire suivante à votre fichier datadog.yaml :

agent_ipc:
  port: 5051
  config_refresh_interval: 3600

Cela garantit que le collecteur DDOT reste synchronisé avec l’Agent après l’actualisation des secrets. De la même manière que l’Agent vérifie périodiquement son état de configuration, le collecteur DDOT utilise ce paramètre pour vérifier régulièrement les valeurs mises à jour de l’Agent.

Dépannage

Liste des secrets détectés

La commande secret dans l’Agent CLI affiche toutes les erreurs liées à votre configuration. Par exemple, si les droits sur l’exécutable sont incorrects. Elle affiche également tous les handles trouvés et leur emplacement.

Sur Linux, la commande affiche le mode de fichier, le propriétaire et le groupe pour l’exécutable. Sur Windows, les droits ACL sont listés.

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

Voir les configurations après l’injection des secrets

Pour voir rapidement comment les configurations de la vérification sont résolues, vous pouvez utiliser la commande 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>
~
===

Remarque : L’Agent doit être redémarré pour prendre en compte les modifications des fichiers de configuration.

Débogage de votre secret_backend_command

Pour tester une commande ou la déboguer en dehors de l’Agent, vous pouvez reproduire la façon dont l’Agent l’exécute :

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