Présentation
Le Datadog Agent vous aide à gérer vos secrets en toute sécurité en s’intégrant aux solutions de gestion des secrets suivantes :
Au lieu de coder en dur des valeurs sensibles comme des clés d’API ou des mots de passe en texte clair dans les 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 la récupération des secrets
Option 1 : Utilisation de la prise en charge native de l’Agent pour récupérer les secrets
Remarques :
- Agent 7.70+ : Prise en charge native de la gestion des secrets introduite.
- Agent 7.76+ : gestion native des secrets disponible pour les agents compatibles FIPS.
- Agent 7.77+ : le Cluster Agent nécessite l’Agent 7.77 ou une version ultérieure dans les environnements conteneurisés. Pour les versions antérieures, utilisez l’Option 2 ou l’Option 3 à la place.
- Agent 7.80+ : prise en charge de plusieurs backends.
Backend unique
Utilisez secret_backend_type et secret_backend_config dans datadog.yaml pour configurer un backend de secrets unique :
# datadog.yaml
secret_backend_type: <backend_type>
secret_backend_config:
<KEY_1>: <VALUE_1>
Des instructions de configuration plus spécifiques dépendent du type de backend utilisé. Consultez la section appropriée ci-dessous pour plus d’informations :
Les services AWS suivants sont pris en charge :
Configurer un profil d’instance
Datadog recommande d’utiliser la méthode du profil d’instance pour récupérer les secrets, car AWS gère toutes les variables d’environnement et les profils de session pour vous. Vous trouverez plus d’instructions sur la façon de procéder dans la documentation officielle d’AWS Secrets Manager.
Exemple de configuration
Configurez le Datadog Agent pour utiliser AWS Secrets afin de résoudre les secrets à l’aide de la configuration suivante :
# datadog.yaml
secret_backend_type: aws.secrets
secret_backend_config:
aws_session:
aws_region: {regionName}
Lorsque vous utilisez des variables d’environnement, convertissez la configuration au format JSON comme suit :
DD_SECRET_BACKEND_TYPE="aws.secrets"
DD_SECRET_BACKEND_CONFIG='{"aws_session":{"aws_region":"<AWS_REGION>"}}'
Une fois l’Agent configuré pour utiliser AWS Secrets, vous pouvez référencer tous les secrets dans vos configurations avec ENC[secretId;secretKey].
La notation ENC est composée :
secretId : soit le « nom convivial » secret (par exemple, /DatadogAgent/Production), soit l’ARN (par exemple, arn:aws:secretsmanager:us-east-1:123456789012:secret:/DatadogAgent/Production-FOga1K).- Remarque : Le format ARN complet est requis lors de l’accès aux secrets depuis un compte différent où l’identifiant AWS ou
sts:AssumeRole est défini.
secretKey : la clé JSON du secret AWS que vous souhaitez utiliser.
AWS Secrets Manager peut stocker plusieurs paires clé-valeur au sein d’un seul secret. Une configuration de backend utilisant Secrets Manager a accès à toutes les clés définies dans un secret.
Par exemple, en supposant que l’ID de secret My-Secrets contienne les 3 valeurs suivantes :
{
"prodApiKey": "datadog api key to use",
"anotherSecret1": "value2",
"anotherSecret2": "value3",
}
Voici un exemple complet du fichier de configuration datadog.yaml utilisant AWS Secrets pour extraire sa clé d’API de My-Secrets :
api_key: ENC[My-Secrets;prodApiKey]
secret_backend_type: aws.secrets
secret_backend_config:
aws_session:
aws_region: us-east-1
Toutes les options aws_session
Les champs aws_session suivants configurent la manière dont l’Agent s’authentifie auprès d’AWS. Tous les champs sont facultatifs ; lorsqu’aucun n’est défini, l’Agent utilise la [default credential chain][1007] (profil d’instance, variables d’environnement, fichier de configuration partagé, etc.).
| Champ | Description |
|---|
aws_region | Région AWS (par exemple, us-east-1). |
aws_access_key_id | ID de clé d’accès AWS statique. À utiliser avec aws_secret_access_key. |
aws_secret_access_key | Clé d’accès secrète AWS statique. À utiliser avec aws_access_key_id. |
aws_profile | Profil nommé issu du fichier de configuration AWS partagé (~/.aws/config). |
aws_role_arn | ARN du rôle IAM à assumer avec sts:AssumeRole. |
aws_external_id | ID externe à transmettre lors de l’assomption d’un rôle inter-comptes. |
force_string option
Définissez force_string: true au niveau supérieur de secret_backend_config pour renvoyer la chaîne de caractères brute du secret au lieu de l’analyser en tant que JSON. Ceci est utile lorsqu’un secret est stocké en texte brut plutôt qu’en tant qu’objet JSON.
secret_backend_type: aws.secrets
secret_backend_config:
force_string: true
aws_session:
aws_region: us-east-1
Configurez le Datadog Agent pour utiliser AWS Secrets afin de résoudre les secrets dans Helm en utilisant la configuration suivante :
Check d’intégration
datadog:
secretBackend:
type: "aws.secrets"
config:
aws_session:
aws_region: "<AWS_REGION>"
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[secretId;secretKey]"
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>
Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les autorisations d'accès au secret AWS.
Check de cluster : sans exécuteurs de check de cluster activés
datadog:
secretBackend:
type: "aws.secrets"
config:
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]"
Check de cluster : avec exécuteurs de check de cluster activés
datadog:
secretBackend:
type: "aws.secrets"
config:
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
rbac:
# IAM role ARN required to grant the Agent permissions to access the AWS secret
serviceAccountAnnotations:
eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
Configurez Datadog Agent pour utiliser AWS Secrets afin de résoudre les secrets avec Datadog Operator en utilisant la configuration suivante :
Remarque : les champs natifs secretBackend nécessitent Datadog Operator v1.29.0+.
Check de l’intégration
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "aws.secrets"
config:
aws_session:
aws_region: <AWS_REGION>
override:
nodeAgent:
# 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]"
Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les autorisations d'accès au secret AWS.
Check de cluster : sans exécuteurs de check de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "aws.secrets"
config:
aws_session:
aws_region: <AWS_REGION>
override:
nodeAgent:
# 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]"
Check de cluster : avec exécuteurs de check de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "aws.secrets"
config:
aws_session:
aws_region: <AWS_REGION>
features:
clusterChecks:
useClusterChecksRunners: true
override:
[...]
clusterChecksRunner:
# 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]"
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config. Par exemple : DD_SECRET_BACKEND_TYPE="aws.secrets" et DD_SECRET_BACKEND_CONFIG='{"aws_session":{"aws_region":"<AWS_REGION>"}}'.
Les services AWS suivants sont pris en charge :
Configurer un profil d’instance
Datadog recommande d’utiliser la méthode du profil d’instance pour récupérer les secrets, car AWS gère toutes les variables d’environnement et les profils de session pour vous. Plus d’instructions sur la façon de procéder sont disponibles dans la documentation officielle d’AWS Secrets Manager.
Exemple de configuration
AWS Systems Manager Parameter Store prend en charge un modèle hiérarchique. Par exemple, en supposant les chemins AWS Systems Manager Parameter Store suivants :
/DatadogAgent/Production/ApiKey = <your_api_key>
/DatadogAgent/Production/ParameterKey2 = ParameterStringValue2
/DatadogAgent/Production/ParameterKey3 = ParameterStringValue3
Les paramètres peuvent être récupérés comme suit :
# 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]"
Toutes les options aws_session
Les champs aws_session suivants configurent la manière dont l’Agent s’authentifie auprès d’AWS. Tous les champs sont facultatifs ; lorsqu’aucun n’est défini, l’Agent utilise la [default credential chain][1007] (profil d’instance, variables d’environnement, fichier de configuration partagé, etc.).
| Champ | Description |
|---|
aws_region | Région AWS (par exemple, us-east-1). |
aws_access_key_id | ID de clé d’accès AWS statique. À utiliser avec aws_secret_access_key. |
aws_secret_access_key | Clé d’accès secrète AWS statique. À utiliser avec aws_access_key_id. |
aws_profile | Profil nommé issu du fichier de configuration AWS partagé (~/.aws/config). |
aws_role_arn | ARN du rôle IAM à assumer avec sts:AssumeRole. |
aws_external_id | ID externe à transmettre lors de l’utilisation d’un rôle inter-comptes. |
Configurez Datadog Agent pour utiliser AWS SSM afin de résoudre les secrets dans Helm en utilisant la configuration suivante :
Check d’intégration
datadog:
secretBackend:
type: "aws.ssm"
config:
aws_session:
aws_region: "<AWS_REGION>"
enableGlobalPermissions: true
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[/DatadogAgent/Production/ParameterKey]"
agents:
rbac:
# IAM role ARN required to grant the Agent permissions to access the AWS SSM parameter
serviceAccountAnnotations:
eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les autorisations d'accès au paramètre AWS SSM.
Check de cluster : sans exécuteurs de check de cluster activés
datadog:
secretBackend:
type: "aws.ssm"
config:
aws_session:
aws_region: "<AWS_REGION>"
enableGlobalPermissions: true
agents:
rbac:
# IAM role ARN required to grant the Agent permissions to access the AWS SSM parameter
serviceAccountAnnotations:
eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[/DatadogAgent/Production/ParameterKey]"
Check de cluster : avec exécuteurs de check de cluster activés
datadog:
secretBackend:
type: "aws.ssm"
config:
aws_session:
aws_region: "<AWS_REGION>"
enableGlobalPermissions: true
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[/DatadogAgent/Production/ParameterKey]"
clusterChecksRunner:
enabled: true
rbac:
# IAM role ARN required to grant the Agent permissions to access the AWS SSM parameter
serviceAccountAnnotations:
eks.amazonaws.com/role-arn: <IAM_ROLE_ARN>
Configurez Datadog Agent pour utiliser AWS SSM afin de résoudre les secrets avec Datadog Operator en utilisant la configuration suivante :
Remarque : les champs natifs secretBackend nécessitent Datadog Operator v1.29.0+.
Check de l’intégration
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "aws.ssm"
config:
aws_session:
aws_region: <AWS_REGION>
override:
nodeAgent:
# IAM role ARN is required to grant the Agent permissions to access the AWS SSM parameter
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[/DatadogAgent/Production/ParameterKey]"
Vous devez inclure le serviceAccountAnnotations pour accorder à l'Agent les autorisations d'accès au paramètre AWS SSM.
Check de cluster : sans exécuteurs de check de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "aws.ssm"
config:
aws_session:
aws_region: <AWS_REGION>
override:
nodeAgent:
# IAM role ARN required to grant the Agent permissions to access the AWS SSM parameter
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[/DatadogAgent/Production/ParameterKey]"
Check de cluster : avec exécuteurs de check de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "aws.ssm"
config:
aws_session:
aws_region: <AWS_REGION>
features:
clusterChecks:
useClusterChecksRunners: true
override:
[...]
clusterChecksRunner:
# IAM role ARN required to grant the Agent permissions to access the AWS SSM parameter
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[/DatadogAgent/Production/ParameterKey]"
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config. Par exemple : DD_SECRET_BACKEND_TYPE="aws.ssm" et DD_SECRET_BACKEND_CONFIG='{"aws_session":{"aws_region":"<AWS_REGION>"}}'.
Les services Azure suivants sont pris en charge :
Authentification Azure
Datadog recommande d’utiliser des Managed Identities pour s’authentifier auprès d’Azure. Cela vous permet d’associer des ressources cloud à des comptes AMI et supprime le besoin d’insérer des informations sensibles dans votre fichier de configuration datadog.yaml.
Managed identity
Pour accéder à votre Key Vault, créez une Managed Identity et affectez-la à votre machine virtuelle. Ensuite, configurez l’attribution de rôle appropriée sur le Key Vault pour permettre à cette identité d’accéder à ses secrets.
Exemple de configuration
La configuration du backend pour les secrets Azure Key Vault est structurée au format YAML selon le schéma suivant :
# datadog.yaml
secret_backend_type: azure.keyvault
secret_backend_config:
keyvaulturl: {keyVaultURL}
azure_session:
azure_client_id: {clientID} # User-assigned managed identity client ID; omit this field for system-assigned
Lorsque vous utilisez des variables d’environnement, convertissez la configuration au format JSON :
DD_SECRET_BACKEND_TYPE="azure.keyvault"
DD_SECRET_BACKEND_CONFIG='{"keyvaulturl": "<keyVaultURL>", "azure_session": {"azure_client_id": "<CLIENT_ID>"}}'
Le secret du backend est référencé dans votre fichier de configuration du Datadog Agent avec ENC[ ]. Voici un exemple où un secret en texte clair doit être récupéré :
# datadog.yaml
api_key: "ENC[secretKeyNameInKeyVault]"
Toutes les options azure_session
Les champs azure_session suivants contrôlent la manière dont l’Agent s’authentifie auprès d’Azure. Tous les champs sont facultatifs — l’Agent recourt à [Default Azure Credential][2001] (variables d’environnement, Workload Identity, system-assigned Managed Identity, Azure CLI, etc.) lorsqu’aucun n’est défini.
| Champ | Description |
|---|
azure_client_id | Client ID d’une user-assigned Managed Identity, ou d’un service principal. |
azure_tenant_id | Tenant ID pour l’authentification par service principal. Requis avec azure_client_id et un secret client ou un certificat. |
azure_client_secret | Secret client pour l’authentification par principal de service. |
azure_client_certificate_path | Chemin d’accès à un fichier de certificat PEM ou PKCS12 pour l’authentification par certificat du service principal. |
azure_client_certificate_password | Mot de passe du fichier de certificat (si protégé par mot de passe). |
azure_client_send_certificate_chain | Définissez sur true pour envoyer la chaîne de certificats complète lors de l’utilisation de l’authentification par certificat. |
L’authentification est sélectionnée en fonction des champs fournis :
- Service principal avec secret :
azure_tenant_id + azure_client_id + azure_client_secret - Service principal avec certificat :
azure_tenant_id + azure_client_id + azure_client_certificate_path - User-assigned Managed Identity :
azure_client_id uniquement - Default Azure Credential (recommandé) : omettez tous les champs
azure_session
Configurez le Datadog Agent pour utiliser Azure Key Vault afin de résoudre les secrets dans Helm en utilisant la configuration suivante :
Check d’intégration
datadog:
secretBackend:
type: "azure.keyvault"
config:
keyvaulturl: "<keyVaultURL>"
azure_session:
azure_client_id: "<CLIENT_ID>"
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[secretKeyNameInKeyVault]"
Check de cluster : sans exécuteurs de check de cluster activés
datadog:
secretBackend:
type: "azure.keyvault"
config:
keyvaulturl: "<keyVaultURL>"
azure_session:
azure_client_id: "<CLIENT_ID>"
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secretKeyNameInKeyVault]"
Check de cluster : avec exécuteurs de check de cluster activés
datadog:
secretBackend:
type: "azure.keyvault"
config:
keyvaulturl: "<keyVaultURL>"
azure_session:
azure_client_id: "<CLIENT_ID>"
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secretKeyNameInKeyVault]"
clusterChecksRunner:
enabled: true
Configurez Datadog Agent pour utiliser Azure Key Vault afin de résoudre les secrets avec Datadog Operator en utilisant la configuration suivante :
Remarque : les champs natifs secretBackend nécessitent Datadog Operator v1.29.0+.
Check de l’intégration
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "azure.keyvault"
config:
keyvaulturl: <KEY_VAULT_URL>
azure_session:
azure_client_id: <CLIENT_ID>
override:
nodeAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[secretKeyNameInKeyVault]"
Check de cluster : sans exécuteurs de check de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "azure.keyvault"
config:
keyvaulturl: <KEY_VAULT_URL>
azure_session:
azure_client_id: <CLIENT_ID>
override:
clusterAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secretKeyNameInKeyVault]"
Check de cluster : avec exécuteurs de check de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "azure.keyvault"
config:
keyvaulturl: <KEY_VAULT_URL>
azure_session:
azure_client_id: <CLIENT_ID>
features:
clusterChecks:
useClusterChecksRunners: true
override:
clusterAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secretKeyNameInKeyVault]"
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config.
Disponible dans la version 7.74+ de l’Agent
Les services GCP suivants sont pris en charge :
Authentification GCP et politique d’accès
L’implémentation de GCP Secret Manager utilise Application Default Credentials (ADC) pour l’authentification auprès de Google.
Pour interagir avec GCP Secret Manager, le compte de service utilisé par le Datadog Agent (tel que le compte de service de la VM, une identité de charge de travail ou des identifiants activés localement) nécessite l’autorisation secretmanager.versions.access.
Celle-ci peut être accordée avec le rôle prédéfini Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) ou un rôle personnalisé avec un accès équivalent.
Sur les environnements d’exécution GCE ou GKE, l’ADC est configuré automatiquement via le compte de service associé à l’instance ou au pod. Le compte de service associé doit disposer des rôles appropriés pour accéder à GCP Secret Manager. De plus, l’environnement d’exécution GCE ou GKE nécessite cloud-platform le périmètre d’accès OAuth.
Exemple de configuration GCP
Configurez le Datadog Agent pour utiliser GCP Secret Manager afin de résoudre les secrets avec la configuration suivante :
# datadog.yaml
secret_backend_type: gcp.secretmanager
secret_backend_config:
gcp_session:
project_id: <PROJECT_ID>
Lorsque vous utilisez des variables d’environnement, convertissez la configuration au format JSON :
DD_SECRET_BACKEND_TYPE="gcp.secretmanager"
DD_SECRET_BACKEND_CONFIG='{"gcp_session":{"project_id":"<PROJECT_ID>"}}'
Après avoir configuré Datadog Agent pour utiliser GCP Secret Manager, référencez les secrets dans vos configurations avec ENC[secret-name] ou ENC[secret-name;key;version;].
La notation ENC est composée :
secret : le nom du secret dans GCP Secret Manager (par exemple, datadog-api-key).key : (facultatif) la clé à extraire d’un secret au format JSON. Si vous utilisez des secrets en texte brut, vous pouvez omettre ceci (exemple : ENC[secret-name;;version]).version : (facultatif) le numéro de version du secret. Si aucune version n’est spécifiée, la version latest est utilisée.- Exemples de syntaxe de version :
secret-key - Version latest implicitesecret-key;;latest - Version latest explicitesecret-key;;1 - Numéro de version spécifique
Par exemple, en supposant des secrets GCP nommés datadog-api-key avec deux versions et 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>
Pour les secrets au format JSON, en supposant qu’un secret nommé datadog-keys contienne :
{
"api_key": "your_api_key_value",
"app_key": "your_app_key_value"
}
Référencez des clés spécifiques comme ceci :
# 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>
Configurez le Datadog Agent pour utiliser GCP Secret Manager afin de résoudre les secrets dans Helm à l’aide de la configuration suivante :
Check de l’intégration
datadog:
secretBackend:
type: "gcp.secretmanager"
config:
gcp_session:
project_id: "<PROJECT_ID>"
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[secret-name]"
Check de cluster : sans exécuteurs de vérification de cluster activés
datadog:
secretBackend:
type: "gcp.secretmanager"
config:
gcp_session:
project_id: "<PROJECT_ID>"
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secret-name]"
Check de cluster : avec exécuteurs de vérification de cluster activés
datadog:
secretBackend:
type: "gcp.secretmanager"
config:
gcp_session:
project_id: "<PROJECT_ID>"
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secret-name]"
clusterChecksRunner:
enabled: true
Configurez Datadog Agent pour utiliser GCP Secret Manager afin de résoudre les secrets avec Datadog Operator à l’aide de la configuration suivante :
Remarque : les champs natifs secretBackend nécessitent Datadog Operator v1.29.0+.
Check de l’intégration
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "gcp.secretmanager"
config:
gcp_session:
project_id: <PROJECT_ID>
override:
nodeAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[secret-name]"
Check de cluster : sans exécuteurs de vérification de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "gcp.secretmanager"
config:
gcp_session:
project_id: <PROJECT_ID>
override:
clusterAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secret-name]"
Check de cluster : avec exécuteurs de vérification de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "gcp.secretmanager"
config:
gcp_session:
project_id: <PROJECT_ID>
features:
clusterChecks:
useClusterChecksRunners: true
override:
clusterAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[secret-name]"
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config.
Gestion des versions des secrets
GCP Secret Manager prend en charge les versions de secret. L’implémentation de l’Agent prend également en charge le versionnage des secrets à l’aide du délimiteur ;. Si aucune version n’est spécifiée, la version latest est utilisée.
Prise en charge des secrets JSON
Le Datadog Agent prend en charge l’extraction de clés spécifiques à partir de secrets au format JSON à l’aide du délimiteur ; :
Les services HashiCorp suivants sont pris en charge :
Comment configurer HashiCorp Vault
- Exécutez votre HashiCorp Vault. Consultez la documentation officielle de HashiCorp Vault pour plus d’informations.
- Rédigez une politique qui donne l’autorisation de récupérer des secrets depuis votre Vault. Créez un fichier
*.hcl et incluez l’autorisation suivante si vous utilisez Secrets Engine Version 1 :
path "<your mount path>/<additional subpath>" {
capabilities = ["read"]
}
Si vous utilisez Secrets Engine Version 2, les autorisations suivantes sont nécessaires :
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"]
}
Exécutez vault policy write <policy_name> <path_to_*.hcl_file>
Choisissez la méthode d’authentification auprès de votre Vault. Si vous utilisez la méthode de profil d’instance AWS, exécutez vault auth enable aws. En cas de déploiement avec Helm ou Datadog Operator, utilisez plutôt la méthode d’authentification Kubernetes.
Instructions pour le profil d’instance AWS
Datadog recommande de vous authentifier en utilisant la méthode de profil d’instance si vous exécutez votre HashiCorp Vault depuis une machine connectée à AWS.
Une fois cela configuré, rédigez une politique Vault spécifique à l’authentification.
Instructions pour la méthode d’authentification Kubernetes
Prérequis : la méthode d’authentification kubernetes de Vault valide le jeton de ServiceAccount de l’Agent en appelant l’API TokenReview de Kubernetes. L’identité utilisée par Vault pour cet appel (son propre ServiceAccount par défaut, ou l’identité définie avec token_reviewer_jwt) doit avoir le ClusterRole system:auth-delegator qui lui est attribué :
kubectl create clusterrolebinding vault-tokenreview-binding \
--clusterrole=system:auth-delegator \
--serviceaccount=<VAULT_NAMESPACE>:<VAULT_SERVICE_ACCOUNT>
Ceci est déjà configuré si vous avez installé Vault avec le chart Helm Vault officiel.
Pour vous authentifier à l’aide du jeton de ServiceAccount Kubernetes du pod de l’Agent (la méthode utilisée par les exemples de configuration Helm et Operator), activez la méthode d’authentification kubernetes dans Vault :
vault auth enable kubernetes
vault write auth/kubernetes/config \
kubernetes_host="https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT"
Créez ensuite un rôle qui lie la politique de l’étape 2 au nom du ServiceAccount et à l’espace de noms de l’Agent :
vault write auth/kubernetes/role/<VAULT_ROLE> \
bound_service_account_names=<AGENT_SERVICE_ACCOUNT_NAME> \
bound_service_account_namespaces=<AGENT_NAMESPACE> \
policies=<policy_name> \
ttl=1h
Utilisez cette valeur <VAULT_ROLE> pour vault_kubernetes_role dans les exemples de configuration Helm et Operator.
Exemple de configuration
Dans l’exemple suivant, supposez que le préfixe du chemin secret HashiCorp Vault est /Datadog/Production avec une clé de paramètre apikey :
/DatadogAgent/Production/apikey: (SecureString) "<your_api_key>"
L’exemple suivant récupère la valeur de la clé d’API depuis HashiCorp Vault en tirant parti d’AWS pour l’authentification.
# 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 # optional, defaults to us-east-1 if not set
Toutes les options vault_session
Les vault_session champs suivants contrôlent la manière dont l’Agent s’authentifie auprès de Vault.
| Champ | Description |
|---|
vault_auth_type | Méthode d’authentification. Valeurs prises en charge : aws, kubernetes. S’il n’est pas défini, AppRole, userpass ou LDAP est utilisé en fonction des informations d’identification fournies. |
vault_role_id | ID de rôle AppRole. À utiliser avec vault_secret_id. |
vault_secret_id | ID secret AppRole. À utiliser avec vault_role_id. |
vault_username | Nom d’utilisateur pour l’authentification userpass. À utiliser avec vault_password. |
vault_password | Mot de passe pour l’authentification userpass. À utiliser avec vault_username. |
vault_ldap_username | Nom d’utilisateur pour l’authentification LDAP. À utiliser avec vault_ldap_password. |
vault_ldap_password | Mot de passe pour l’authentification LDAP. À utiliser avec vault_ldap_username. |
vault_aws_role | Nom du rôle Vault pour l’authentification AWS IAM. Requis lorsque vault_auth_type: aws. |
vault_aws_iam_server_id | Valeur pour l’en-tête X-Vault-AWS-IAM-Server-ID, utilisée pour empêcher les attaques par rejeu. |
aws_region | Région AWS pour les demandes d’authentification IAM. La valeur par défaut est us-east-1. |
vault_kubernetes_role | Nom du rôle Vault pour l’authentification Kubernetes. Requis lorsque vault_auth_type: kubernetes. |
vault_kubernetes_jwt | Jeton JWT du compte de service Kubernetes sous forme de chaîne. |
vault_kubernetes_jwt_path | Chemin vers le fichier de jeton JWT Kubernetes. La valeur par défaut est /var/run/secrets/kubernetes.io/serviceaccount/token. |
vault_kubernetes_mount_path | Chemin de montage Vault pour la méthode d’authentification Kubernetes. |
implicit_auth | Définissez sur true pour ignorer l’authentification et utiliser le jeton déjà défini dans l’environnement client Vault (par exemple, VAULT_TOKEN). |
Autres options secret_backend_config pour Vault
Les champs de premier niveau secret_backend_config suivants s’appliquent également :
| Champ | Description |
|---|
vault_address | Adresse du serveur Vault (par exemple, http://myvaultaddress.net). Peut également être défini avec la variable d’environnement VAULT_ADDR. |
vault_token | Jeton Vault statique. À utiliser lorsqu’aucune méthode d’authentification n’est utilisée. |
vault_namespace | Espace de noms Vault pour les environnements Vault Enterprise. |
Configuration TLS (vault_tls_config)
Pour activer le TLS mutuel ou une autorité de certification personnalisée, ajoutez un bloc vault_tls_config :
secret_backend_type: hashicorp.vault
secret_backend_config:
vault_address: https://myvaultaddress.net
vault_tls_config:
ca_cert: /path/to/ca.pem
client_cert: /path/to/client.pem
client_key: /path/to/client-key.pem
insecure: false
| Champ | Description |
|---|
ca_cert | Chemin vers un fichier de certificat d’autorité de certification encodé en PEM. |
ca_path | Chemin vers un répertoire de fichiers de certificat d’autorité de certification encodés en PEM. |
client_cert | Chemin vers un fichier de certificat client encodé en PEM pour le mTLS. |
client_key | Chemin vers le fichier de clé privée du certificat client. |
tls_server | Nom de serveur attendu pour la vérification SNI TLS. |
insecure | Définissez sur true pour désactiver la vérification du certificat TLS. Ne pas utiliser en production. |
Configurez Datadog Agent pour utiliser HashiCorp Vault afin de résoudre les secrets dans Helm en utilisant la configuration suivante. Ceci utilise la méthode d’authentification kubernetes de Vault, qui repose sur le jeton ServiceAccount automatiquement monté de l’Agent, donc aucun RBAC Kubernetes ou annotation supplémentaire n’est requis pour l’Agent. Vault lui-même a besoin d’autorisations RBAC pour valider ce jeton ; consultez les instructions de la méthode d’authentification Kubernetes ci-dessus.
Remarque : Dans votre serveur Vault, activez la méthode d’authentification kubernetes et liez vault_kubernetes_role au nom du ServiceAccount et à l’espace de noms de l’Agent. Consultez les instructions de la méthode d’authentification Kubernetes ci-dessus et la [documentation officielle de la méthode d’authentification Kubernetes de HashiCorp Vault][3005] pour plus d’informations.
Check de l’intégration
datadog:
secretBackend:
type: "hashicorp.vault"
config:
vault_address: "https://myvaultaddress.net"
vault_session:
vault_auth_type: kubernetes
vault_kubernetes_role: "<VAULT_ROLE>"
vault_kubernetes_mount_path: "auth/kubernetes/login"
enableGlobalPermissions: true
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[/Datadog/Production;apikey]"
Check de cluster : sans exécuteurs de vérification de cluster activés
datadog:
secretBackend:
type: "hashicorp.vault"
config:
vault_address: "https://myvaultaddress.net"
vault_session:
vault_auth_type: kubernetes
vault_kubernetes_role: "<VAULT_ROLE>"
vault_kubernetes_mount_path: "auth/kubernetes/login"
enableGlobalPermissions: true
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[/Datadog/Production;apikey]"
Check de cluster : avec exécuteurs de vérification de cluster activés
datadog:
secretBackend:
type: "hashicorp.vault"
config:
vault_address: "https://myvaultaddress.net"
vault_session:
vault_auth_type: kubernetes
vault_kubernetes_role: "<VAULT_ROLE>"
vault_kubernetes_mount_path: "auth/kubernetes/login"
enableGlobalPermissions: true
clusterAgent:
confd:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[/Datadog/Production;apikey]"
clusterChecksRunner:
enabled: true
Configurez Datadog Agent pour utiliser HashiCorp Vault afin de résoudre les secrets avec Datadog Operator en utilisant la configuration suivante. Ceci utilise la méthode d’authentification kubernetes de Vault, qui repose sur le jeton ServiceAccount automatiquement monté de l’Agent, donc aucun RBAC Kubernetes ou annotation supplémentaire n’est requis pour l’Agent. Vault lui-même a besoin d’autorisations RBAC pour valider ce jeton ; consultez les instructions de la méthode d’authentification Kubernetes ci-dessus.
Remarque : les champs natifs secretBackend nécessitent Datadog Operator v1.29.0+. Dans votre serveur Vault, activez la méthode d’authentification kubernetes et liez vault_kubernetes_role au nom du ServiceAccount et à l’espace de noms de l’Agent. Consultez les instructions de la méthode d’authentification Kubernetes ci-dessus et la [documentation officielle de la méthode d’authentification Kubernetes de HashiCorp Vault][3005] pour plus d’informations.
Check de l’intégration
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "hashicorp.vault"
config:
vault_address: "https://myvaultaddress.net"
vault_session:
vault_auth_type: kubernetes
vault_kubernetes_role: "<VAULT_ROLE>"
vault_kubernetes_mount_path: "auth/kubernetes/login"
override:
nodeAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
ad_identifiers:
- <SHORT_IMAGE>
instances:
- [...]
password: "ENC[/Datadog/Production;apikey]"
Check de cluster : sans exécuteurs de vérification de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "hashicorp.vault"
config:
vault_address: "https://myvaultaddress.net"
vault_session:
vault_auth_type: kubernetes
vault_kubernetes_role: "<VAULT_ROLE>"
vault_kubernetes_mount_path: "auth/kubernetes/login"
override:
clusterAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[/Datadog/Production;apikey]"
Check de cluster : avec exécuteurs de vérification de cluster activés
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
[...]
global:
secretBackend:
type: "hashicorp.vault"
config:
vault_address: "https://myvaultaddress.net"
vault_session:
vault_auth_type: kubernetes
vault_kubernetes_role: "<VAULT_ROLE>"
vault_kubernetes_mount_path: "auth/kubernetes/login"
features:
clusterChecks:
useClusterChecksRunners: true
override:
clusterAgent:
extraConfd:
configDataMap:
# This is an example
<INTEGRATION_NAME>.yaml: |-
cluster_check: true
instances:
- [...]
password: "ENC[/Datadog/Production;apikey]"
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config. Par exemple : DD_SECRET_BACKEND_TYPE="hashicorp.vault" et DD_SECRET_BACKEND_CONFIG='{"vault_address":"https://myvaultaddress.net","vault_session":{"vault_auth_type":"kubernetes","vault_kubernetes_role":"<VAULT_ROLE>","vault_kubernetes_mount_path":"auth/kubernetes/login"}}'.
Disponible dans la version 7.75+ de l’Agent
Les services Kubernetes suivants sont pris en charge :
Prérequis
Le backend de secrets Kubernetes nécessite :
- Identifiants ServiceAccount : Par défaut, utilise des jetons ServiceAccount montés automatiquement (
automountServiceAccountToken: true, voir documentation Kubernetes). Des chemins personnalisés peuvent être configurés si nécessaire. - Autorisations RBAC : Le ServiceAccount de l’Agent doit disposer des autorisations nécessaires pour lire les secrets des espaces de noms cibles
- Accès réseau : Le pod de l’Agent doit pouvoir atteindre le serveur API Kubernetes
Configuration RBAC
Pour chaque espace de noms contenant des secrets, créez un Role et un RoleBinding en utilisant l’exemple suivant avec le nom d’espace de noms correct :
# 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
Exemple de configuration
Configurez le Datadog Agent pour utiliser les Secrets Kubernetes avec la configuration suivante :
# 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]"
Le format de notation ENC est namespace/secret-name;key :
namespace : Le Kubernetes namespace contenant le secretsecret-name : Le nom de la ressource Secretkey : La clé spécifique à extraire du champ de données du Secret
Exemple : Étant donné un Secret dans le Kubernetes namespace 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>
Vous pouvez référencer des clés individuelles :
api_key: "ENC[secrets-ns/dd-api-key;api_key]"
app_key: "ENC[secrets-ns/dd-api-key;app_key]"
Prise en charge multi-namespace :
Chaque référence de secret peut spécifier un Kubernetes namespace différent (RBAC doit être configuré pour chacun) :
api_key: "ENC[secrets-ns/dd-keys;api_key]"
db_password: "ENC[secrets-shared/db-creds;password]"
Configurez le Datadog Agent pour utiliser les Secrets Kubernetes avec Helm :
# values.yaml
datadog:
apiKey: "placeholder-will-be-overridden"
secretBackend:
type: "k8s.secrets"
env:
- name: DD_API_KEY
value: "ENC[secrets-ns/dd-api-key;api_key]"
Remarque : Un espace réservé apiKey est requis pour la validation du chart Helm lors de l’utilisation du backend de secrets pour résoudre la clé d’API. La variable d’environnement DD_API_KEY la remplace. Vous devez créer manuellement le RBAC (Role + RoleBinding) pour chaque Kubernetes namespace contenant des secrets. Pour plus d’informations, consultez la section Configuration RBAC.
Alternativement, vous pouvez utiliser la variable d’environnement DD_SECRET_BACKEND_TYPE au lieu du champ natif datadog.secretBackend.type.
Configurez Datadog Agent pour utiliser les Secrets Kubernetes avec Datadog Operator :
Remarque : Les champs natifs secretBackend nécessitent Datadog Operator v1.25.0+.
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
credentials:
apiKey: "placeholder-will-be-overridden"
secretBackend:
type: "k8s.secrets"
override:
nodeAgent:
env:
- name: DD_API_KEY
value: "ENC[secrets-ns/dd-api-key;api_key]"
Remarque : Une clé d’API d’espace réservé satisfait la validation de l’Opérateur lors de l’utilisation du backend de secrets pour résoudre la clé d’API. La variable d’environnement DD_API_KEY la remplace. Vous devez créer manuellement le RBAC (Role + RoleBinding) pour chaque Kubernetes namespace contenant des secrets. Pour plus d’informations, consultez la section Configuration RBAC.
Alternativement, vous pouvez utiliser la variable d’environnement DD_SECRET_BACKEND_TYPE au lieu du champ natif spec.global.secretBackend.type.
Configuration de chemin personnalisé
Si votre configuration ne suit pas les emplacements par défaut pour l’authentification basée sur ServiceAccount, vous pouvez spécifier token_path et ca_path à la place.
secret_backend_type: k8s.secrets
secret_backend_config:
token_path: /custom/path/to/token
ca_path: /custom/path/to/ca.crt
Remarque : Les champs natifs secretBackend nécessitent le chart Helm v3.171.0+.
datadog:
secretBackend:
type: "k8s.secrets"
config:
token_path: /custom/path/to/token
ca_path: /custom/path/to/ca.crt
enableGlobalPermissions: true
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs datadog.secretBackend.type et datadog.secretBackend.config.
Remarque : Les champs natifs secretBackend nécessitent Datadog Operator v1.25.0+.
spec:
global:
secretBackend:
type: "k8s.secrets"
config:
token_path: /custom/path/to/token
ca_path: /custom/path/to/ca.crt
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config.
Configuration de serveur API personnalisé
Si votre configuration n’expose pas les variables d’environnement par défaut KUBERNETES_SERVICE_HOST et KUBERNETES_SERVICE_PORT, vous pouvez fournir une URL api_server pour interagir avec l’API REST de Kubernetes.
secret_backend_type: k8s.secrets
secret_backend_config:
api_server: https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}
Remarque : Les champs natifs secretBackend nécessitent le chart Helm v3.171.0+.
datadog:
secretBackend:
type: "k8s.secrets"
config:
api_server: https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}
enableGlobalPermissions: true
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs datadog.secretBackend.type et datadog.secretBackend.config.
Remarque : Les champs natifs secretBackend nécessitent Datadog Operator v1.25.0+.
spec:
global:
secretBackend:
type: "k8s.secrets"
config:
api_server: https://{KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config.
Disponible dans la version 7.75+ de l’Agent
Les services Docker suivants sont pris en charge :
Prérequis
Le backend de secrets Docker prend en charge à la fois les Docker Swarm secrets et les Docker Compose secrets. Par défaut, Swarm et Compose montent automatiquement les secrets dans le conteneur sous forme de fichiers à /run/secrets (Linux) ou C:\ProgramData\Docker\secrets (Windows).
Remarque : Les secrets Compose peuvent être basés sur des fichiers (pointant vers des fichiers locaux) ou externes (faisant référence à des secrets Swarm existants).
Exemple de configuration
Configurez le Datadog Agent pour utiliser Docker Secrets avec la configuration suivante :
# datadog.yaml
secret_backend_type: docker.secrets
# Reference secrets using the secret name (filename in /run/secrets)
api_key: "ENC[dd_api_key]"
Le format de notation ENC est le nom du secret, qui correspond au nom de fichier dans /run/secrets/ :
ENC[api_key] lit depuis /run/secrets/api_key (Linux) ou C:\ProgramData\Docker\secrets\api_key (Windows)
Chemin d’accès personnalisé aux secrets :
Si Docker Swarm ou Docker Compose sont configurés pour monter des secrets à un emplacement différent, vous pouvez le spécifier comme suit :
secret_backend_type: docker.secrets
secret_backend_config:
secrets_path: /custom/secrets/path
Exemple Docker Swarm
Créer et utiliser un secret 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
Le secret dd_api_key est automatiquement monté sur /run/secrets/dd_api_key, et l’Agent le lit en utilisant le backend docker.secrets.
Exemple Docker Compose
Créer un docker-compose.yml avec des secrets basés sur des fichiers :
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
Le fichier secret ./secrets/api_key.txt est monté à /run/secrets/dd_api_key dans le conteneur.
| valeur de secret_backend_type | Service de fichiers |
|---|
file.json | JSON |
file.yaml | YAML |
file.text | TEXT |
Autorisations de fichier
Le backend de fichier nécessite uniquement des autorisations de lecture pour les fichiers JSON, YAML ou TEXT configurés. Ces autorisations doivent être accordées à l’utilisateur local du Datadog Agent (dd-agent sous Linux, ddagentuser sous Windows).
Remarque : seul un niveau de profondeur JSON est pris en charge (par exemple, {"key": "value"})
Exemple de configuration
Vous pouvez utiliser un fichier JSON pour stocker des secrets localement.
Par exemple, avec un fichier JSON dans /path/to/secret.json contenant ce qui suit :
{
"datadog_api_key": "your_api_key"
}
Vous pouvez utiliser cette configuration pour en extraire les secrets :
# datadog.yaml
api_key: "ENC[datadog_api_key]"
secret_backend_type: file.json
secret_backend_config:
file_path: /path/to/secret.json
Remarque : Un seul niveau de profondeur YAML est pris en charge (par exemple, key: value)
Exemple de configuration
Vous pouvez utiliser un fichier YAML pour stocker des secrets localement.
À titre d’exemple, si nous avons un fichier YAML dans /path/to/secret.yaml contenant :
datadog_api_key: your api key
Vous pouvez utiliser la configuration suivante pour en extraire des secrets :
# datadog.yaml
api_key: "ENC[datadog_api_key]"
secret_backend_type: file.yaml
secret_backend_config:
file_path: /path/to/secret.yaml
Disponible dans la version 7.75+ de l’Agent
Remarque : Chaque secret doit être stocké dans son propre fichier texte individuel.
Exemple de configuration
Vous pouvez utiliser des fichiers texte individuels pour stocker des secrets localement.
Par exemple, avec des fichiers texte dans /path/to/secrets/ :
/path/to/secrets/dd_api_key contenant :
/path/to/secrets/dd_app_key contenant :
Vous pouvez utiliser cette configuration pour en extraire les secrets :
# 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
Sécurité du chemin :
- Les chemins relatifs dans
ENC[] sont résolus par rapport à secrets_path (par ex., ENC[dd_api_key] avec secret_path: /path/to/secrets sera résolu en /path/to/secrets/dd_api_key) - Les chemins absolus dans
ENC[] doivent se trouver dans secrets_path (par ex., ENC[/path/to/secrets/dd_api_key] avec secret_path: /path/to/secrets fonctionnera) - Les tentatives de parcours de répertoire (par ex.
ENC[../etc/passwd]) sont bloquées et échoueront avec le message « path outside allowed directory »
Remarque : Certains outils ajoutent automatiquement des sauts de ligne lors de l’exportation de secrets vers des fichiers. Consultez Supprimer les sauts de ligne de fin pour savoir comment gérer cela.
Déploiement avec Helm ou Datadog Operator
Pour utiliser un backend de secrets basé sur des fichiers (file.json, file.yaml ou file.text) avec Helm ou Datadog Operator, montez le fichier de secrets dans chaque composant Agent qui le résout. Les exemples suivants le montent uniquement dans l’Agent de nœud. Si le Cluster Agent ou le Cluster Checks Runner contient une valeur ENC[], montez le même volume dans ce composant. Remplacez file.yaml ou file.text et la clé de configuration correspondante (file_path ou secrets_path) selon les besoins.
datadog:
secretBackend:
type: "file.json"
config:
file_path: /etc/secret-volume/secret.json
enableGlobalPermissions: true
agents:
volumes:
- name: secret-volume
secret:
secretName: <SECRET_NAME>
volumeMounts:
- name: secret-volume
mountPath: /etc/secret-volume
readOnly: true
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs datadog.secretBackend.type et datadog.secretBackend.config.
Remarque : Les champs natifs secretBackend nécessitent Datadog Operator v1.25.0+.
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
secretBackend:
type: "file.json"
config:
file_path: /etc/secret-volume/secret.json
override:
nodeAgent:
volumes:
- name: secret-volume
secret:
secretName: <SECRET_NAME>
containers:
agent:
volumeMounts:
- name: secret-volume
mountPath: /etc/secret-volume
readOnly: true
Alternativement, vous pouvez utiliser les variables d’environnement DD_SECRET_BACKEND_TYPE et DD_SECRET_BACKEND_CONFIG au lieu des champs natifs spec.global.secretBackend.type et spec.global.secretBackend.config.
Disponible dans la version 7.82+ de l’Agent
Les services Windows suivants sont pris en charge :
| Valeur secret_backend_type | Service |
|---|
windows.regkey | Registre Windows |
Prérequis
Ce backend est pris en charge sur Windows uniquement. La clé de registre doit être lisible par le compte sous lequel le Datadog Agent s’exécute (par défaut ddagentuser). Les clés sous HKLM sont lisibles par tous les utilisateurs locaux par défaut. Datadog recommande de restreindre l’ACL afin que seuls ddagentuser et SYSTEM puissent lire la clé.
Exemple de configuration
Configurez le Datadog Agent pour utiliser le backend Windows Registry Key avec la configuration suivante :
# datadog.yaml
secret_backend_type: windows.regkey
api_key: 'ENC[SOFTWARE\Datadog\secrets:api_key]'
Référencez les secrets en utilisant le format ENC[<registry-path>:<value-name>], où registry-path est le sous-chemin sous la clé racine et value-name est la valeur de registre à lire.
Par défaut, la clé racine est HKLM. Pour utiliser une ruche différente, définissez root_key. Seules les valeurs suivantes sont acceptées (toute autre valeur renvoie une erreur) :
HKLM, HKCU, HKCR, HKU, HKCC (les formes longues telles que HKEY_LOCAL_MACHINE sont également prises en charge)
secret_backend_type: windows.regkey
secret_backend_config:
root_key: HKCU
Configurer la clé de registre
Cet exemple de script shell PowerShell montre comment configurer un registre (à exécuter en tant qu’administrateur après l’installation) :
# Create the key and set the secret value
New-Item -Path "HKLM:\SOFTWARE\Datadog\secrets" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Datadog\secrets" -Name "api_key" -Value "<YOUR_API_KEY>"
# Restrict read access to ddagentuser and SYSTEM (recommended)
$acl = Get-Acl "HKLM:\SOFTWARE\Datadog\secrets"
$acl.SetAccessRuleProtection($true, $false)
$acl.SetAccessRule((New-Object System.Security.AccessControl.RegistryAccessRule -ArgumentList "SYSTEM", "ReadKey", "Allow"))
$acl.SetAccessRule((New-Object System.Security.AccessControl.RegistryAccessRule -ArgumentList "ddagentuser", "ReadKey", "Allow"))
$acl.SetAccessRule((New-Object System.Security.AccessControl.RegistryAccessRule -ArgumentList "Administrators", "FullControl", "Allow"))
Set-Acl "HKLM:\SOFTWARE\Datadog\secrets" $acl
Plusieurs backends
Disponible dans la version 7.80+ de l’Agent
Au lieu d’un secret_backend_type unique, vous pouvez déclarer plusieurs backends nommés sous multi_secret_backends. Chaque backend possède ses propres type et config, et les secrets sont acheminés vers un backend spécifique en utilisant un préfixe backendName; dans le handle ENC[].
Si plusieurs des paramètres suivants sont définis, le paramètre ayant la priorité la plus élevée prend effet et les autres sont ignorés avec un avertissement :
secret_backend_commandsecret_backend_typemulti_secret_backends
Configuration
# datadog.yaml
multi_secret_backends:
<backend_name>:
type: <backend_type>
config:
<KEY_1>: <VALUE_1>
Chaque <backend_name> est un identifiant arbitraire que vous choisissez. Il ne peut pas contenir de point-virgule, car ; est le délimiteur utilisé dans les handles ENC[]. Les champs type et config suivent le même schéma que secret_backend_type et secret_backend_config pour le backend correspondant.
ENC[] notation
Lorsque multi_secret_backends est actif, faites précéder les handles ENC[] du nom du backend suivi d’un point-virgule :
ENC[<backend_name>;<secret_key>]
Seul le premier point-virgule est traité comme le délimiteur de backend. Les clés secrètes qui contiennent elles-mêmes des points-virgules (par exemple, namespace/secret-name;key de style Kubernetes) continuent de fonctionner.
Exemple
La configuration suivante lit les secrets à partir de deux backends de fichiers simultanément :
# datadog.yaml
multi_secret_backends:
yaml_secrets:
type: file.yaml
config:
file_path: /etc/datadog-agent/secrets.yaml
aws_secrets:
type: aws.secrets
config:
aws_session:
aws_region: us-east-1
Référencez les secrets en les faisant précéder du nom du backend :
# datadog.yaml
api_key: ENC[yaml_secrets;api_key]
app_key: ENC[aws_secrets;My-Secrets;appKey]
Migration depuis secret_backend_type
Pour passer d’un secret_backend_type unique à multi_secret_backends :
- Déplacez
secret_backend_type et secret_backend_config dans une entrée nommée sous multi_secret_backends. - Supprimez
secret_backend_type et secret_backend_config du niveau supérieur. - Mettez à jour tous les handles
ENC[secretKey] vers ENC[backendName;secretKey].
# Before
secret_backend_type: file.yaml
secret_backend_config:
file_path: /etc/datadog-agent/secrets.yaml
api_key: ENC[api_key]
# After
multi_secret_backends:
my_yaml:
type: file.yaml
config:
file_path: /etc/datadog-agent/secrets.yaml
api_key: ENC[my_yaml;api_key]
Option 2 : Utilisation du script intégré pour Kubernetes et Docker
Disponible dans la version 7.32+ de l’Agent
Pour les environnements conteneurisés, les images de conteneur du Datadog Agent incluent un script intégré /readsecret_multiple_providers.sh. Ce script prend en charge la lecture de secrets à partir de :
- Fichiers : en utilisant
ENC[file@/path/to/file] - Secrets Kubernetes : en utilisant
ENC[k8s_secret@namespace/secret-name/key]
Pour utiliser cet exécutable avec Datadog Operator, configurez-le comme suit :
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
secretBackend:
command: "/readsecret_multiple_providers.sh"
Pour utiliser cet exécutable avec le chart Helm, définissez-le comme suit :
datadog:
[...]
secretBackend:
command: "/readsecret_multiple_providers.sh"
Pour utiliser cet exécutable, définissez la variable d’environnement DD_SECRET_BACKEND_COMMAND comme suit :
DD_SECRET_BACKEND_COMMAND=/readsecret_multiple_providers.sh
Exemple : Lecture à partir de fichiers montés
Kubernetes prend en charge l’exposition de secrets sous forme de 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 nommage que le pod dans lequel il est monté.
- Le script est capable d’accéder à tous les sous-dossiers, y compris le dossier sensible
/var/run/secrets/kubernetes.io/serviceaccount/token. À ce titre, Datadog recommande d’utiliser un dossier dédié plutôt que /var/run/secrets.
Les secrets 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. Celui-ci serait référencé dans la configuration avec ENC[file@/run/secrets/db_prod_password].
Exemple : Lecture d’un secret Kubernetes entre différents espaces de nommage
Si vous souhaitez que l’Agent lise un Secret provenant d’un espace de nommage différent, utilisez le préfixe k8s_secret@. Exemple :
password: ENC[k8s_secret@database/database-secret/password]
Configurez le RBAC pour permettre au compte de service de l’Agent de lire le Secret. Le rôle suivant accorde un accès en lecture au Secret database-secret dans l’espace de nommage database :
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
secretBackend:
command: "/readsecret_multiple_providers.sh"
roles:
- namespace: database
secrets:
- "database-secret"
Remarque : Chaque espace de nommage dans la liste des rôles doit également être configuré dans la variable d’environnement WATCH_NAMESPACE ou DD_AGENT_WATCH_NAMESPACE sur le déploiement de Datadog Operator.
datadog:
(...)
secretBackend:
command: "/readsecret_multiple_providers.sh"
roles:
- namespace: database
secrets:
- database-secret
Sinon, vous pouvez définir directement les ressources 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: ""
Ceci Role donne accès au Secret: database-secret dans le Namespace: database. Le RoleBinding lie cette autorisation au ServiceAccount: datadog-agent dans le Namespace: default. Ceci 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 la durée 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 des 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 descripteurs de secrets à résoudre. Ensuite, votre exécutable récupère chaque secret et les renvoie dans un format JSON via une sortie standard.
L’exemple suivant montre ce que l’Agent envoie à votre exécutable sur STDIN :
{
"version": "1.0",
"secrets": ["secret1", "secret2"]
}
version (chaîne) : La version du format.secrets (liste de chaînes) : Chaque chaîne est un descripteur pour un secret à récupérer.
L’exécutable répond via la sortie STDOUT suivante :
{
"secret1": {"value": "decrypted_value", "error": null},
"secret2": {"value": null, "error": "could not fetch the secret"}
}
value (chaîne) : La valeur du secret à utiliser dans les configurations. Cela peut être null en cas d’erreur.error (chaîne) : Un message d’erreur ou null.
Si un secret ne peut pas être résolu (soit en renvoyant 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 de statut 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 renvoie 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))
}
Ceci transforme votre configuration :
instances:
- server: db_prod
user: ENC[db_prod_user]
password: ENC[db_prod_password]
En mémoire, cela se présente comme suit:
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.
Sur Linux, votre exécutable doit :
- Appartenir au même utilisateur que celui exécutant l’Agent (
dd-agent par défaut, ou root dans un conteneur). - Ne disposer d’aucun droit pour
group ou other. - Avoir au moins le droit d’exécution pour le propriétaire.
Sur Windows, votre exécutable doit :
- Avoir les droits de lecture ou d’exécution pour
ddagentuser (l’utilisateur utilisé pour exécuter l’Agent). - Ne disposer d’aucun droit pour tout utilisateur ou groupe, à l’exception du groupe Administrators, du compte intégré Local System ou du contexte utilisateur de l’Agent (
ddagentuser par défaut). - Être une application Win32 valide afin que l’Agent puisse l’exécuter (par exemple, un script PowerShell ou Python ne fonctionne pas).
Remarque : Votre exécutable partage les mêmes variables d’environnement que l’Agent.
Actualisation des secrets au moment de l’exécution
Disponible dans la version 7.67+ de l’Agent
Vous pouvez configurer l’Agent pour actualiser les secrets résolus sans nécessiter de redémarrage.
Définissez un intervalle d’actualisation :
secret_refresh_interval: 3600 # refresh every hour
Ou déclenchez une actualisation manuellement :
datadog-agent secret refresh
Actualisation de la clé d’API/APP
Les clés d’API/APP récupérées en tant que secrets prennent en charge l’actualisation au moment de l’exécution.
Vous pouvez activer cette fonctionnalité 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 l’actualisation initiale dans la fenêtre secret_refresh_interval pour empêcher un parc de
afin que les Agents ne s’actualisent pas simultanément. La clé est résolue au démarrage, puis actualisée une fois au cours du premier intervalle
et à chaque intervalle par la suite.
Pour éviter tout downtime, n’invalidez les anciennes clés qu’une fois que l’ensemble de votre parc a récupéré les clés mises à jour. Vous pouvez suivre l’utilisation
des clés sur la page Gestion du parc.
Vous pouvez désactiver ce comportement en définissant :
secret_refresh_scatter: false
Actualisation des secrets lors du check Autodiscovery
Disponible dans la version 7.76+ de l’Agent
Les checks Autodiscovery planifiés peuvent actualiser les secrets au moment de l’exécution 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é d’API
Disponible dans la version 7.74+ de l’Agent
L’Agent peut automatiquement rafraîchir les secrets lorsqu’il détecte une clé d’API invalide. Cela se produit lorsque l’Agent reçoit une réponse 403 Forbidden de Datadog ou lorsque le check périodique de l’état détecte une clé d’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 la durée minimale entre 2 rafraîchissements pour éviter de spammer votre solution de gestion des secrets lorsqu’une clé d’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.
Activer le rafraîchissement du collecteur DDOT
Si vous utilisez le collecteur DDOT et souhaitez activer le rafraîchissement 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 le rafraîchissement des secrets. Tout comme l’Agent vérifie périodiquement l’état de sa configuration, le collecteur DDOT utilise ce paramètre pour vérifier régulièrement les valeurs mises à jour provenant de l’Agent.
Dépannage
Lister les secrets détectés
La commande secret dans l’interface de ligne de commande de l’Agent affiche toutes les erreurs liées à votre configuration. Par exemple, si les droits sur l’exécutable sont incorrects. La commande affiche également tous les descripteurs trouvés et leur emplacement.
Sous Linux, la commande affiche le mode de fichier, le propriétaire et le groupe de l’exécutable. Sous Windows, les droits ACL sont listés.
Exemple sous 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
Exemple sous Windows (en tant qu’administrateur 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
Voir les configurations après l’injection des secrets
Pour voir rapidement comment les configurations de check 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 apportées aux 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 :
Linux
sudo -u dd-agent bash -c "echo '{\"version\": \"1.0\", \"secrets\": [\"secret1\", \"secret2\"]}' | /path/to/the/secret_backend_command"
L’utilisateur dd-agent est créé lors de l’installation du Datadog Agent.
Les erreurs suivantes indiquent qu’il manque quelque chose dans votre configuration.
Si un groupe ou un utilisateur autre que celui requis dispose de droits sur l’exécutable, une erreur similaire à la suivante est consignée :
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
Si ddagentuser ne dispose pas des droits de lecture et d’exécution sur le fichier, une erreur similaire est consignée :
error while decrypting secrets in an instance: could not query ACLs for C:\decrypt.exe
Votre exécutable doit être une application Win32 valide. Si ce n’est pas le cas, l’erreur suivante est consignée :
error while running 'C:\decrypt.py': fork/exec C:\decrypt.py: %1 is not a valid Win32 application.
Datadog propose un script Powershell pour vous aider à définir les autorisations correctes sur votre exécutable. Exemple d’utilisation :
.\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:
Test de votre exécutable
Votre exécutable est lancé par l’Agent lors de la récupération de vos secrets. Le Datadog Agent s’exécute en utilisant le ddagentuser. Cet utilisateur ne dispose d’aucun droit spécifique, mais il fait partie du groupe Performance Monitor Users. Le mot de passe de cet utilisateur est généré de manière aléatoire lors de l’installation et n’est jamais enregistré nulle part.
Cela signifie que votre exécutable peut fonctionner avec votre utilisateur par défaut ou votre utilisateur de développement, mais pas lorsqu’il est exécuté par l’Agent, car ddagentuser dispose de droits plus restreints.
Pour tester votre exécutable dans les mêmes conditions que l’Agent, mettez à jour le mot de passe du ddagentuser sur votre machine de développement. De cette façon, vous pouvez vous authentifier en tant que ddagentuser et exécuter votre exécutable dans le même contexte que celui de l’Agent.
Pour ce faire, suivez ces étapes :
- Supprimez
ddagentuser de la liste Local Policies/User Rights Assignement/Deny Log on locally dans le Local Security Policy. - Définissez un nouveau mot de passe pour
ddagentuser (car celui généré lors de l’installation n’est jamais enregistré nulle part). Dans PowerShell, exécutez :$user = [ADSI]"WinNT://./ddagentuser";
$user.SetPassword("a_new_password")
- Mettez à jour le mot de passe à utiliser par le service
DatadogAgent dans le Gestionnaire de contrôle des services. Dans PowerShell, exécutez :sc.exe config DatadogAgent password= "a_new_password"
Vous pouvez maintenant vous connecter en tant que ddagentuser pour tester votre exécutable. Datadog dispose d’un script Powershell pour vous aider à tester votre
exécutable en tant qu’autre utilisateur. Il change de contexte utilisateur et imite la façon dont l’Agent exécute votre exécutable.
Exemple d’utilisation :
.\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
L’Agent refuse de démarrer
La première chose que fait l’Agent au démarrage est de charger datadog.yaml et de déchiffrer tous les secrets qu’il contient. Cela est effectué avant la configuration de la journalisation. Cela signifie que sur des plateformes comme Windows, les erreurs survenant lors du chargement de datadog.yaml ne sont pas écrites dans les logs, mais sur stderr. Cela peut se produire lorsque l’exécutable fourni à l’Agent pour les secrets renvoie une erreur.
Si vous avez des secrets dans datadog.yaml et que l’Agent refuse de démarrer :
- Essayez de démarrer l’Agent manuellement pour pouvoir voir
stderr. - Supprimez les secrets de
datadog.yaml et testez d’abord avec des secrets dans un fichier de configuration de check.
Test des autorisations Kubernetes
Lors de la lecture directe des secrets depuis Kubernetes, vous pouvez vérifier vos autorisations avec la commande kubectl auth. La forme générale de ceci est :
kubectl auth can-i get secret/<SECRET_NAME> -n <SECRET_NAMESPACE> --as system:serviceaccount:<AGENT_NAMESPACE>:<AGENT_SERVICE_ACCOUNT>
Considérez l’exemple précédent de Secrets Kubernetes, où le Secret Secret:database-secret existe dans le Namespace: database, et le Compte de service ServiceAccount:datadog-agent existe dans le Namespace: default.
Pour cet exemple, utilisez la commande suivante :
kubectl auth can-i get secret/database-secret -n database --as system:serviceaccount:default:datadog-agent
Cette commande indique si l’Agent dispose des autorisations adéquates pour accéder à ce secret.
Supprimer les sauts de ligne de fin
Certains outils de gestion des secrets ajoutent automatiquement un saut de ligne lors de l’exportation de secrets via des fichiers. Vous pouvez supprimer ces sauts de ligne en définissant secret_backend_remove_trailing_line_break: true dans le fichier de configuration datadog.yaml, ou utiliser la variable d’environnement DD_SECRET_BACKEND_REMOVE_TRAILING_LINE_BREAK pour faire de même, en particulier dans les environnements conteneurisés.
Variables d’Autodiscovery dans secret handles
Il est également possible d’utiliser des variables Autodiscovery dans secret handles. L’Agent résout ces variables avant de résoudre le secret. Exemple :
instances:
- server: %%host%%
user: ENC[db_prod_user_%%host%%]
password: ENC[db_prod_password_%%host%%]
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles:
