Gestion des secrets

Avec la gestion des secrets, vous pouvez configurer l'agent et l'intégration sur l'hôte pour utiliser des données sensibles (telles que les mots de passe) sans avoir à les écrire en texte brut dans les fichiers configuration . Actuellement, Hashicorp Vault, AWS KMS, CyberArk, l'obfuscation CLI New Relic et les commandes personnalisées sont pris en charge.

Apprenez-en plus dans cette vidéo NerdBytes (5:12 minutes).

Définir les secrets

Pour utiliser des secrets dans un fichier de configuration YAML :

1. Définissez une section variables , où chaque entrée est un nom pour un objet secret.
2. Dans chaque entrée, incluez la source du secret et la configuration appropriée pour récupérer ces secrets.
3. Dans la section configuration générale, définissez ${variable.property} espace réservé qui sera automatiquement remplacé par les propriétés de l'objet secret. L'objet secret peut être défini comme une simple chaîne ou un objet json.

Par exemple, la configuration suivante récupérera un objet nommé creds dans Vault (vous pouvez définir le nom de l'objet pour le secret). Supposons que l'objet stocké est un JSON valide avec une propriété nommée user et une autre propriété nommée password. Nous souhaitons les utiliser pour définir les informations d'identification HTTP de base de la propriété status_url à partir d'une intégration Nginx sur hôte :

variables:
  creds:
    vault:
      http:
        url: http://my.vault.host/v1/newengine/data/secret
        headers:
          X-Vault-Token: my-vault-token
integrations:
  - name: nri-nginx
    env:
      METRICS: "true"
      STATUS_URL: http://${creds.user}:${creds.password}@example.com/status
      STATUS_MODULE: discover
      REMOTE_MONITORING: true
    interval: 30s
    labels:
      env: production
      role: load_balancer

Utilisation des variables d'environnement

Les variables d'environnement peuvent être utilisées dans la section variables avec la notation {{MY_ENV_VAR}} . Ce faisant, les variables d’environnement sont développées et leur valeur est remplacée au moment de l’exécution.

Utilisez cette méthode pour éviter d’avoir des valeurs sensibles telles que des jeton ou des clés obfuscation incluses dans le fichier configuration .

Lors de l'utilisation de variables d'environnement dans les fichiers configuration intégration sur hôte, le paramètre passthrough_environment doit être défini.

Variables secrètes

Définissez des secrets dans chaque configuration sous une section variables . Chaque entrée est un nom secret défini par l'utilisateur qui stockera les propriétés des secrets récupérés. Chaque variable peut contenir les propriétés suivantes :

Les secrets d'AWS KMS

Pour récupérer vos secrets depuis Amazon KMS, vous pouvez définir les propriétés suivantes dans votre section aws-kms . Tous les champs ne sont pas obligatoires. Par exemple, vous aurez besoin de data, file ou http pour fournir la chaîne KMS codée.

L'exemple suivant permettra de récupérer une chaîne de mot de passe simple à partir d'AWS KMS. Il doit être déchiffré à partir de la chaîne codée data fournie.

variables:
  myPassword:
    aws-kms:
      data: T0hBSStGTEVY
      region: ap-southeast-2
      credential_file: "./my-aws-credentials-file"
      config_file: "./my-aws-config-file"
      type: plain

Les secrets du coffre-fort

Vault doit activer un champ http contenant la configuration HTTP utilisée pour se connecter à Vault. L'entrée http peut contenir les entrées suivantes :

Propriétés de tls_config

L'exemple suivant récupère un secret à l'aide d'un jeton Vault à partir d'un serveur sécurisé et ignore la vérification des certificats du serveur :

variables:
  mydata:
    vault:
      http:
        url: https://my.vault.host/v1/newengine/data/secret
        headers:
          X-Vault-Token: my-vault-token
        tls_config:
          insecure_skip_verify: true

Interface de ligne de commande CyberArk

Pour récupérer des secrets à partir de l'interface de ligne de commande CyberArk (CLI), utilisez la configuration suivante, toutes les clés sont requises

L'exemple suivant récupère un secret CyberArk à l'aide de l'interface de ligne de commande :

variables:
  credentials:
    cyberark-cli:
      cli: /full/path/to/clipasswordsdk
      app-id: my-appid
      safe: my-safe
      folder: my-folder
      object: my-object

REST API CyberArk

Pour récupérer des secrets à l'aide de la REST API CyberArk, il doit y avoir une clé http contenant la configuration HTTP. La clé http contient ces sous-clés, seule url est requise :

L'exemple suivant récupère un secret à l'aide de la REST API CyberArk, en ignorant la vérification du certificat du serveur :

variables:
  credentials:
    cyberark-api:
      http:
        url: https://hostname/AIMWebService/api/Accounts?AppID=myAppID&Query=Safe=mySafe;Object=myObject
        tls_config:
          insecure_skip_verify: true

En vous référant à l'exemple ci-dessus, appelez le nom d'utilisateur et le mot de passe comme ceci :

USERNAME: ${credentials.user}
   PASSWORD: ${credentials.password}

Remarque : pour Microsoft SQL Server, si vous utilisez une connexion utilisateur d’authentification Windows, vous devez préfixer le USERNAME avec votre domaine. Par exemple:

USERNAME: <domain>\${credentials.user}

Obfuscation de la CLI de New Relic

Vous pouvez utiliser la commande obfuscate de l'interface de ligne de commande New Relic pour masquer les informations sensibles dans l'agent infrastructure ou dans tout fichier configuration intégration sur hôte.

Mesures:

• Installez la CLI New Relic sur n’importe quel hôte (il peut s’agir de votre hôte de développement).
• Exécutez la commande CLI obfuscate afin de générer la valeur obscurcie :

newrelic agent config obfuscate --value '<plain_text_config_value>' --key '<obfuscation_key>'

• Copiez le résultat de la commande cli dans l’argument text de la section obfuscated comme indiqué dans les exemples ci-dessous.
• Vous pouvez obscurcir les blocs JSON si vous devez référencer plusieurs valeurs dans votre fichier YML de configuration. Notez que vous devrez peut-être échapper aux guillemets "" avec des barres obliques inverses sur les hôtes Windows. Par exemple : '{\"attribute\":\"value\".... De plus, utilisez Powershell sur les hôtes Windows , plutôt que la fenêtre d'invitation de commande, car la fenêtre d'invitation de commande peut gérer les guillemets de manière inattendue.

newrelic agent config obfuscate --value '{"attribute":"value","attribute2":"value2"}' --key '<obfuscation_key>'

Integrations configuration example

L'exemple suivant permettra de récupérer l'utilisateur et le mot de passe Nginx qui ont été obscurcis à l'aide de la CLI New Relic. Cet exemple utilise la notation par points lors de la récupération des informations d'identification, car la valeur obscurcie était un bloc JSON :

variables:
  creds:
    obfuscated:
      key: 'random_key_used_in_cli'
      secret: 'obscured_output_from_cli'
integrations:
  - name: nri-nginx
    env:
      METRICS: "true"
      STATUS_URL: http://${creds.user}:${creds.password}@example.com/status
      STATUS_MODULE: discover
      REMOTE_MONITORING: true
    interval: 30s
    labels:
      env: production
      role: load_balancer

Il est recommandé d'utiliser des variables d'environnement pour les arguments d'obfuscation comme indiqué dans l'exemple ci-dessous :

variables:
  creds:
    obfuscated:
      key: {{OBFUSCATION_KEY}}
      secret: {{OBFUSCATION_TEXT}}
integrations:
  - name: nri-nginx
    env:
      METRICS: "true"
      STATUS_URL: http://${creds.user}:${creds.password}@example.com/status
      STATUS_MODULE: discover
      REMOTE_MONITORING: true
    interval: 30s
    labels:
      env: production
      role: load_balancer

Agent configuration example

Cet exemple permet de récupérer une chaîne contenant les détails du proxy (utilisateur, mot de passe et hôte) :

variables:
  obfuscated_proxy:
    obfuscated:
      key: 'random_key_used_in_cli'
      secret: 'obscured_output_from_cli'

proxy: ${obfuscated_proxy}

Commandes personnalisées

Vous pouvez charger la configuration de l'agent ou de l'intégration à partir de commandes personnalisées disponibles sur le même hôte. L'agent infrastructure détectera quand la configuration doit être initialement chargée à partir d'une sortie command et conservera les valeurs à jour en fonction d'un temps d'actualisation ttl.

Le format de sortie attendu pour la commande est soit JSON, soit String :

JSON

La structure JSON suivante est attendue comme sortie principale (stdout) à partir du command défini :

{
  "data": {
    "myKey": "myValue"
  }, 
  "ttl": "24h"
}

• Un champ data de niveau supérieur est obligatoire.
• Un champ ttl de niveau supérieur est obligatoire.

Il peut ensuite être utilisé dans n’importe quel fichier de configuration utilisant la notation ${myVariable.key} . Dans l'exemple suivant, une commande my-custom-auth est exécutée avec un paramètre domain puis charge le token résultant en tant que configuration d'agent :

variables:
  myToken:
    command:
      path: '/path/to/my-custom-auth-json'
      args: ["--domain", "myDomain", "--other_param", "otherValue"] 
      ttl: 24h
      
# my-custom-auth output example: {"data":{"token":"XXXXYYYYZZZZ"}, "ttl": "24h"}
# the `token` result can be included as ${myToken.token} in any configuration.
  
http:
  headers: 
    "Proxy-Authorization": ${myToken.token}

Chaîne (texte/plaine)

Si la sortie de la commande est une chaîne simple, elle peut être référencée dans la configuration à l'aide de la notation ${myVar} .

Exemple:

variables:
  myToken:
    command:
      path: '/path/to/my-custom-auth-string'
      args: ["arg1", "arg2"] 
      ttl: 24h
      
# my-custom-auth output example: "XXXXYYYYZZZZ"
# the `token` result can be included as ${myToken} on any configuration.
  
http:
  headers: 
    "Proxy-Authorization": ${myToken}