Gerenciamento de segredos

Com o gerenciamento de segredos, você pode configurar o agente e a integração no host para usar dados confidenciais (como senhas) sem precisar gravá-los como texto simples nos arquivos de configuração. Atualmente, Hashicorp Vault, AWS KMS, CyberArk, ofuscação CLI New Relic e comandos personalizados são suportados.

Saiba mais neste vídeo do NerdBytes (5:12 minutos).

Definir segredos

Para usar segredos em um arquivo YAML de configuração:

1. Defina uma seção variables, onde cada entrada é um nome para um objeto secreto.
2. Em cada entrada, inclua a origem do segredo e a configuração adequada para recuperar esses segredos.
3. Na seção de configuração geral, defina ${variable.property} espaço reservado que será automaticamente substituído pelas propriedades do objeto secreto. O objeto secreto pode ser definido como uma string simples ou um objeto JSON.

Por exemplo, a configuração a seguir recuperará um objeto chamado creds do Vault (você pode definir o nome do objeto para o segredo). Vamos supor que o objeto armazenado seja um JSON válido com uma propriedade chamada user e outra propriedade chamada password. Queremos usá-los para definir as credenciais HTTP básicas da propriedade status_url de uma integração Nginx no host:

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 variáveis de ambiente

Variáveis de ambiente podem ser usadas na seção variables com a notação {{MY_ENV_VAR}} . Ao fazer isso, as variáveis de ambiente são expandidas e seu valor é substituído em tempo de execução.

Use este método para evitar que valores confidenciais, como token ou chaves de ofuscação, sejam incluídos no arquivo de configuração.

Ao usar variáveis de ambiente em arquivos de configuração de integração no host, a configuração passthrough_environment deve ser definida.

Variáveis de segredos

Defina segredos em cada configuração em uma seção variables . Cada entrada é um nome de segredo definido pelo usuário que armazenará as propriedades dos segredos recuperados. Cada variável pode conter as seguintes propriedades:

Segredos do AWS KMS

Para recuperar seus segredos do Amazon KMS, você pode definir as propriedades a seguir na seção aws-kms . Nem todos os campos são obrigatórios. Por exemplo, você precisará de data, file ou http para fornecer a string KMS codificada.

O exemplo a seguir permitirá recuperar uma string de senha simples do AWS KMS. Ele deve ser descriptografado da string codificada data fornecida.

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

Segredos do cofre

O Vault deve ativar um campo http contendo a configuração HTTP usada para conectar-se ao Vault. A entrada http pode conter as seguintes entradas:

Propriedades tls_config

O exemplo a seguir recuperará um segredo usando um token do Vault de um servidor seguro e ignorará a verificação dos certificados do 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

Interface de linha de comando CyberArk

Para recuperar segredos da interface de linha de comando (CLI) CyberArk, use a seguinte configuração, todas as chaves são necessárias

O exemplo a seguir recuperará um segredo do CyberArk usando a interface de linha 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 CyberArk

Para recuperar segredos usando a API REST CyberArk, deve haver uma chave http contendo a configuração HTTP. A chave http contém estas subchaves, apenas url é necessária:

O exemplo a seguir recuperará um segredo usando a API REST do CyberArk, ignorando a verificação do certificado do 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

Ofuscação New Relic CLI

Você pode usar o comando ofuscate da CLI do New Relic para ocultar informações confidenciais no agente de infraestrutura ou em qualquer arquivo de configuração de integração no host.

Passos:

• Instale a CLI do New Relic em qualquer host (pode ser seu host de desenvolvimento).
• Execute o comando CLI ofuscate para gerar o valor ofuscado:

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

• Copie o resultado do comando cli no argumento text na seção obfuscated conforme mostrado nos exemplos abaixo.
• Você pode ofuscar blocos JSON se precisar fazer referência a vários valores em seu arquivo YML de configuração. Observe que pode ser necessário escapar das aspas "" com barras invertidas em hosts Windows. Por exemplo: '{\"attribute\":\"value\".... Além disso, use o Powershell em hosts Windows, em vez da janela do prompt de comando, pois a janela do prompt de comando pode lidar com aspas de maneiras inesperadas.

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

Integrations configuration example

O exemplo a seguir permitirá recuperar o usuário e a senha do Nginx que foram ofuscados usando a CLI do New Relic. Este exemplo usa notação de ponto ao recuperar as credenciais, pois o valor ofuscado era um bloco 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

É recomendado usar variáveis de ambiente para os argumentos de ofuscação, conforme mostrado no exemplo abaixo:

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 exemplo permite recuperar uma string que contém os detalhes do proxy (usuário, senha e host):

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

proxy: ${obfuscated_proxy}

Comandos personalizados

Você pode carregar o agente ou a configuração de integração a partir de comandos customizados disponíveis no mesmo host. O agente de infraestrutura detectará quando a configuração deve ser inicialmente carregada a partir de uma saída command e manterá os valores atualizados com base em um tempo de atualização ttl .

O formato de saída esperado para o comando é JSON ou String:

JSON

A seguinte estrutura JSON é esperada como saída principal (stdout) do command definido:

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

• Um campo data de nível superior é obrigatório.
• Um campo ttl de nível superior é obrigatório.

Ele pode então ser usado em qualquer arquivo de configuração usando a notação ${myVariable.key} . No exemplo a seguir, um comando my-custom-auth é executado com um parâmetro domain e depois carrega o token resultante como uma configuração 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}

String (texto/simples)

Se a saída do comando for uma string simples, ela poderá ser referenciada na configuração usando a notação ${myVar} .

Exemplo:

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}