Gestion des secrets

Présentation

Observability Pipelines Worker vous aide à gérer vos secrets de manière sécurisée en s’intégrant à la solution de gestion des secrets suivante :

  • AWS Secrets Manager
  • AWS Systems Manager
  • Azure Key Vault
  • HashiCorp Vault
  • Fichier JSON
  • Fichier YAML

Remarques :

  • Si vous souhaitez utiliser des secrets Kubernetes, suivez les instructions de Configuration de toutes les paires clé-valeur dans un Secret en tant que variables d’environnement de conteneur et configurez le secret en tant que variable d’environnement pour Observability Pipelines Worker.
  • Lorsque vous configurez un pipeline et installez le Worker, si vous saisissez des identifiants de secret puis choisissez d’utiliser des variables d’environnement, la variable d’environnement est l’identifiant saisi précédé de DD_OP. Par exemple, si vous avez saisi PASSWORD_1 pour un identifiant de mot de passe, la variable d’environnement pour ce mot de passe est DD_OP_PASSWORD_1.

Configurez le Worker pour récupérer des secrets

Configurez un profil d’instance AWS

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. Consultez la documentation officielle d’AWS Secrets Manager pour obtenir les instructions de configuration.

Configurez le Worker pour utiliser AWS Secrets Manager

    Après avoir installé le Worker, configurez le fichier d’amorçage du Worker pour résoudre les secrets à l’aide d’AWS Secrets Manager :

    backend_type: aws
backend_config:
  aws_session:
    aws_region: <region_name>

    Avant d’installer le Worker, ajoutez la configuration d’amorçage à la section datadog.bootstrap.config du fichier values.yaml du chart Helm :

    bootstrap:
  config:
    secret:
      backend_type: aws
      backend_config:
        aws_session:
          aws_region: <region_name>

    Les paramètres aws_session suivants sont disponibles :

    SettingDescription
    aws_regionRégion AWS
    aws_profileProfil de session AWS
    aws_role_arnAWS sts:AssumeRole ARN
    aws_external_idAWS sts:AssumeRole ExternalId
    aws_access_key_idAWS IAM User Access Key ID
    aws_secret_access_keyAWS IAM User Access Key Secret

    Dans la plupart des cas, vous devez spécifier aws_region pour correspondre à la région hébergeant le secret Secrets Manager.

    Lors du traitement de chaînes uniques, le paramètre de configuration du backend force_string: true force le secret à être une valeur de chaîne.

    Configurez un profil d’instance AWS

    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. Consultez la documentation officielle AWS Systems Manager Parameter Store pour les instructions de configuration.

    Configurez le Worker pour utiliser AWS Systems Manager

      Après avoir installé le Worker, configurez le fichier d’amorçage du Worker pour résoudre les secrets à l’aide d’AWS Systems Manager :

      secret:
  backend_type: aws_parameter_store
  backend_config:
    aws_session:
      aws_region: <region_name>

      Avant d’installer le Worker, ajoutez la configuration d’amorçage à la section datadog.bootstrap.config du fichier values.yaml du chart Helm :

      bootstrap:
  config:
    secret:
      backend_type: aws_parameter_store
      backend_config:
        aws_session:
          aws_region: <region_name>

      Configurer l’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’inclure des informations sensibles dans votre fichier de configuration Worker.

      Créer une identité gérée

      Pour accéder à votre Key Vault, créez une identité gérée et assignez-la à votre VM. Ensuite, configurez l’attribution de rôle appropriée sur le Key Vault pour permettre à l’identité gérée d’accéder aux secrets.

      Configurez le Worker pour utiliser Azure Key Vault

        Après avoir installé le Worker, configurez le fichier d’amorçage du Worker pour résoudre les secrets en utilisant Azure Key Vault :

        backend_type: azure
backend_config:
  keyvaulturl: <key_vault_url>

        Avant d’installer le Worker, ajoutez la configuration d’amorçage à la section datadog.bootstrap.config du fichier values.yaml du chart Helm :

        bootstrap:
  config:
    secret:
      backend_type: azure
      backend_config:
        keyvaulturl: <key_vault_url>

        Configurez HashiCorp Vault

        1. Exécutez votre HashiCorp Vault. Consultez la documentation officielle de HashiCorp Vault pour plus d’informations.

        2. 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 la version 1 du moteur de secrets :

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

          Si vous utilisez la version 2 du moteur de secrets, 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"]
}

        3. Exécutez vault policy write <policy_name> <path_to_*.hcl_file>.

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

        Configurez un profil d’instance AWS pour une machine connectée à 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.

        Configurez le Worker pour utiliser HashiCorp Vault

          Après avoir installé le Worker, configurez le fichier d’amorçage du Worker pour résoudre les secrets avec HashiCorp Vault :

          secret:
  backend_type: vault
  backend_config:
    vault_address: http://myvaultaddress.net
    vault_tls_config:
      # ... TLS settings if applicable
    vault_session:
      vault_auth_type: aws
      # ... additional session settings

          Avant d’installer le Worker, ajoutez la configuration d’amorçage à la section datadog.bootstrap.config du fichier values.yaml du chart Helm :

          bootstrap:
  config:
    secret:
      backend_type: vault
      backend_config:
        vault_address: http://myvaultaddress.net
        vault_tls_config:
          # ... TLS settings if applicable
        vault_session:
          vault_auth_type: aws
          # ... additional session settings

          Autorisations de fichier requises

          Le backend de fichier nécessite uniquement des autorisations de lecture pour les fichiers JSON configurés. Ces autorisations doivent être accordées à l’utilisateur local du Worker.

          Configurez le Worker pour utiliser un backend de secrets de fichier JSON

            Après avoir installé le Worker, configurez le fichier d’amorçage du Worker pour résoudre les secrets avec un fichier JSON :

            secret:
  backend_type: json
  backend_config:
    file_path: /path/to/json/file.json

            Créez un fichier de secrets JSON

            Créez le fichier /path/to/json/file.json pour stocker les identifiants et leurs valeurs secrètes :

            {
  "us1_api": "<api_key>",
  "secret_identifier1": "<secret1>"
}

            Vous ne pouvez pas transmettre de fichier pour configurer secretFileContents, mais vous pouvez ajouter vos secrets et le mappage des identifiants à la section datadog.bootstrap.secretFileContents du fichier values.yaml du chart Helm :

            bootstrap:
  secretFileContents:
    us1_api: "<api_key>"
    secret_identifier1: "<secret1>"

            Autorisations de fichier requises

            Le backend de fichier nécessite uniquement des autorisations de lecture pour les fichiers YAML configurés. Ces autorisations doivent être accordées à l’utilisateur local du Worker.

            Configurez le Worker pour utiliser un backend de secrets de fichier YAML

              Après avoir installé le Worker, configurez le fichier d’amorçage du Worker pour résoudre les secrets avec un fichier YAML :

              secret:
  backend_type: yaml
  backend_config:
    file_path: /path/to/yaml/file.yaml

              Créer un fichier de secrets YAML

              Créez le fichier /path/to/yaml/file.yaml pour stocker les identifiants et leurs valeurs secrètes :

              # /path/to/yaml/file.yaml

us1_api: "<api_key>"
secret_identifier1: "<secret1>"

              Vous ne pouvez pas transmettre de fichier pour configurer secretFileContents, mais vous pouvez ajouter vos secrets et le mappage des identifiants à la section datadog.bootstrap.secretFileContents du fichier values.yaml du chart Helm :

              bootstrap:
  secretFileContents:
    us1_api: "<api_key>"
    secret_identifier1: "<secret1>"

              Actualisez les secrets au moment de l’exécution

              Observability Pipelines Worker résout les secrets au démarrage et lors du rechargement de sa configuration. Pour prendre en compte les valeurs secrètes renouvelées sans redémarrer le Worker, envoyez un signal SIGHUP.

              Remarque : Si un secret renouvelé a une valeur non valide, le rechargement échoue. Datadog recommande d’effectuer le rechargement un Worker ou un nœud à la fois et de vérifier l’état de santé du Worker avant de continuer.

                Envoyez SIGHUP au processus Worker :

                kill -HUP <worker_pid>

                Envoyez SIGHUP au processus Worker à l’intérieur de chaque pod :

                kubectl exec <pod_name> -- kill -HUP 1

                Pour aller plus loin

                Documentation, liens et articles supplémentaires utiles:

                Configurez des pipelinesDOCUMENTATION more more Installez le WorkerDOCUMENTATION more more