• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.

Criar um problema

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.

Importante

Se a recuperação dos segredos falhar, a integração não será executada, pois o agente de infraestrutura não possui todos os dados necessários para executar.

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

Dica

Tanto strings simples quanto objetos JSON válidos podem ser recuperados de variáveis.
Ao usar objetos JSON, certifique-se de que as chaves e os valores estejam entre aspas duplas.

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:

Chave YAML

Descrição

ttl

Tipo: Corda

Quantidade de tempo antes que um segredo seja atualizado. Pode ser um número seguido por uma unidade de tempo (s, m ou h).

Exemplos: 30s, 10m, 1h

Padrão: 1h

aws-kms

Configuração de recuperação de segredo AWS KMS

vault

Configuração de recuperação de segredo do Vault

cyberark-cli

Configuração da interface de linha de comando do CyberArk

cyberark-api

Configuração API REST do CyberArk

obfuscated

Ofuscação New Relic CLI

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.

Chave YAML

Descrição

data

Tipo: Corda

String KMS codificada em Base64 para descriptografar

file

Tipo: Corda

Caminho para o arquivo que contém a string KMS codificada em Base64 para descriptografar

http

Tipo: propriedades YAML

Configuração HTTP a ser usada para solicitar a string KMS codificada em Base64 para descriptografar. Para obter mais informações, consulte Cofre http.

credential_file

Tipo: Corda

Caminho para o arquivo de credenciais da AWS

config_file

Tipo: Corda

Caminho para o arquivo de configuração da AWS

region

Tipo: Corda

Região AWS KMS

type

Tipo: String (plain, equal ou json)

Formato do valor secreto:

  • plain: uma string bruta a ser armazenada diretamente na variável de destino.

  • equal: uma string de uma linha key=property a ser armazenada como propriedades do objeto na variável de destino.

  • json: um objeto JSON a ser armazenado como propriedades na variável de destino.

    Os segredos do tipo plain ou json usam notação de ponto; por exemplo, ${mysecret.nestedkey}.

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:

Chave YAML

Descrição

url

Tipo: Corda

URL para solicitar dados

tls_config

Tipo: propriedades YAML

Use as propriedades de configuração TLS

headers

Tipo: mapa YAML

Solicitar cabeçalhos

Propriedades tls_config

Importante

Os segredos devem usar notação de ponto, por exemplo, ${mysecret.nestedkey}.

Chave YAML

Descrição

enable

Tipo: Booleano

Habilitar TLS

Padrão: false

insecure_skip_verify

Tipo: Booleano

Ignorar a verificação da cadeia de certificados e do host do servidor

Padrão: false

min_version

Tipo: UInt16

A versão SSL/TLS mínima aceitável

Padrão: 0 (que usa TLS versão 1.0)

max_version

Tipo: UInt16

A versão SSL/TLS máxima aceitável

Padrão: 0 (que usa TLS versão 1.3)

ca

Tipo: Corda

Certificado TLS

""

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

Chave YAML

Descrição

cli

Tipo: string

Caminho completo para o executável CyberArk CLI

Padrão: ""

app-eu ia

Tipo: string

ID do aplicativo do detentor do segredo

Padrão: ""

safe

Tipo: string

Cofre contendo o segredo

Padrão: ""

folder

Tipo: string

Pasta contendo o segredo

Padrão: ""

object

Tipo: string

O objeto ao qual o segredo está associado

Padrão: ""

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:

Chave YAML

Descrição

url

Tipo: Corda

URL para solicitar dados, esta chave é obrigatória

Padrão: nenhum

tls_config

Tipo: propriedades YAML

Use as propriedades de configuração TLS

headers

Tipo: mapa YAML

Solicitar cabeçalhos

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

Referindo-se ao exemplo acima, chame o nome de usuário e a senha assim:

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

Observação: para o Microsoft SQL Server, se você usar um login de usuário de autenticação do Windows, deverá prefixar USERNAME com seu domínio. Por exemplo:

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

Ofuscação New Relic CLI

Importante

Recomendamos usar qualquer um dos provedores de segredos suportados em vez da simples ofuscação, quando possível.

Consulte nossas diretrizes abaixo para definir variáveis de ambiente e evitar a chave de ofuscação nos arquivos de configuração.

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.

Dica

O agente de infraestrutura 1.14.0 ou superior é necessário

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:

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>'

Chave YAML

Descrição

chave

Tipo: Corda

A string usada ao ofuscar o valor de texto simples usando a CLI do New Relic

Padrão: nenhum

secret

Tipo: Corda

A saída do comando newrelic-cli

Padrão: nenhum

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

Importante

A configuração command requer o agente de infraestrutura 1.41.0 ou superior. Certifique-se de que o agente tenha as permissões necessárias para executar o command configurado com base nos requisitos do seu ambiente.

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}
Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.