Gestión de secretos

Con la administración de secretos, puede configurar el agente y la integración en el host para usar datos confidenciales (como contraseñas) sin tener que escribirlos como texto sin formato en los archivos de configuración. Actualmente, se admiten Hashicorp Vault, AWS KMS, CyberArk, la ofuscación CLI de New Relic y los comandos personalizados.

Obtenga más información en este video de NerdBytes (5:12 minutos).

Definir secretos

Para usar secretos en un archivo YAML de configuración:

1. Defina una sección variables, donde cada entrada sea un nombre para un objeto secreto.
2. En cada entrada, incluya la fuente del secreto y la configuración adecuada para recuperar esos secretos.
3. En la sección de configuración general, establezca ${variable.property} marcador de posición que será reemplazado automáticamente por las propiedades del objeto secreto. El objeto secreto se puede definir como una cadena simple o un objeto json.

Por ejemplo, la siguiente configuración recuperará un objeto llamado creds de Vault (puede definir el nombre del objeto para el secreto). Supongamos que el objeto almacenado es un JSON válido con una propiedad denominada user y otra propiedad denominada password. Queremos usarlos para configurar las credenciales HTTP básicas de la propiedad status_url desde una integración en el host de Nginx:

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

Usando variables de entorno

Las variables de entorno se pueden utilizar en la sección variables con la notación {{MY_ENV_VAR}} . Al hacerlo, las variables de entorno se expanden y su valor se reemplaza en tiempo de ejecución.

Utilice este método para evitar que se incluyan valores confidenciales como tokens o claves de ofuscación en el archivo de configuración.

Cuando se utilizan variables de entorno en archivos de configuración de integración en el host, se debe definir la configuración passthrough_environment .

Variables secretas

Defina secretos en cada configuración en una sección variables . Cada entrada es un nombre secreto definido por el usuario que almacenará las propiedades de los secretos recuperados. Cada variable puede contener las siguientes propiedades:

Secretos de AWS KMS

Para recuperar sus secretos de Amazon KMS, puede configurar las siguientes propiedades en su sección aws-kms . No todos los campos son obligatorios. Por ejemplo, necesitará data, file o http para proporcionar la cadena KMS codificada.

El siguiente ejemplo permitirá recuperar una cadena de contraseña simple de AWS KMS. Debe descifrarse de la cadena codificada data proporcionada.

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

Secretos de la bóveda

Vault debe habilitar un campo http que contenga la configuración HTTP utilizada para conectarse a Vault. La entrada http puede contener las siguientes entradas:

Propiedades tls_config

El siguiente ejemplo recuperará un secreto utilizando un token de Vault de un servidor seguro y omitirá la verificación de los certificados del servidor:

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

Interfaz de línea de comando de CyberArk

Para recuperar secretos de la interfaz de línea de comando (CLI) de CyberArk utilice la siguiente configuración, se requieren todas las claves

El siguiente ejemplo recuperará un secreto de CyberArk utilizando la interfaz de línea de comando:

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

API REST de CyberArk

Para recuperar secretos utilizando la API REST de CyberArk, debe haber una clave http que contenga la configuración HTTP. La clave http contiene estas subclaves; solo se requiere url :

El siguiente ejemplo recuperará un secreto utilizando la API REST de CyberArk, omitiendo la verificación del certificado del servidor:

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

Ofuscación CLI New Relic

Puede utilizar el comando ofuscate de la CLI de New Relic para ocultar información confidencial en el agente de infraestructura o en cualquier archivo de configuración de integración en el host.

Pasos:

• Instale la CLI de New Relic en cualquier host (puede ser su host de desarrollo).
• Ejecute el comando CLI ofuscate para generar el valor ofuscado:

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

• Copie el resultado del comando cli en el argumento text en la sección obfuscated como se muestra en los ejemplos siguientes.
• Puede ofuscar bloques JSON si necesita hacer referencia a varios valores en su archivo YML de configuración. Tenga en cuenta que es posible que deba evitar las comillas "" con barras invertidas en hosts de Windows. Por ejemplo: '{\"attribute\":\"value\".... Además, utilice Powershell en hosts de Windows, en lugar de la ventana del símbolo del sistema, ya que la ventana del símbolo del sistema puede manejar las comillas de formas inesperadas.

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

Integrations configuration example

El siguiente ejemplo permitirá recuperar el usuario y la contraseña de Nginx que se han ofuscado mediante la CLI de New Relic. Este ejemplo utiliza notación de puntos al recuperar las credenciales, ya que el valor ofuscado era un bloque 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

Se recomienda utilizar variables de entorno para los argumentos de ofuscación, como se muestra en el siguiente ejemplo:

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

Este ejemplo permite recuperar una cadena que contiene los detalles del proxy (usuario, contraseña y host):

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

proxy: ${obfuscated_proxy}

Comandos personalizados

Puede cargar configuración de agente o integración desde comandos personalizados disponibles en el mismo host. El agente de infraestructura detectará cuándo se debe cargar inicialmente la configuración desde una salida command y mantendrá los valores actualizados en función de un tiempo de actualización ttl .

El formato de salida esperado para el comando es JSON o Cadena:

JSON

Se espera la siguiente estructura JSON como salida principal (stdout) del command definido:

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

• Se requiere un campo data de nivel superior.
• Se requiere un campo ttl de nivel superior.

Luego se puede utilizar en cualquier archivo de configuración utilizando la notación ${myVariable.key} . En el siguiente ejemplo, se ejecuta un comando my-custom-auth con un parámetro domain y luego se carga el token resultante como una configuración de agente:

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}

Cadena (texto/sin formato)

Si el resultado del comando es una cadena simple, se puede hacer referencia a ella en la configuración utilizando la notación ${myVar} .

Ejemplo:

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}