Configurar un proxy para el agente eBPF de New Relic

Si su entorno enruta el tráfico saliente a través de un proxy corporativo, puede configurar el eBPF agent de New Relic para enviar telemetría OTLP a través de ese proxy. Esta página explica cómo configurar el soporte para proxy en hosts de Linux y clústeres de Kubernetes, los requisitos del servidor proxy y cómo solucionar problemas comunes.

Cómo funciona el soporte para proxy

El eBPF agent utiliza el soporte de proxy HTTP integrado de gRPC. Cuando configura un proxy, el agente:

1. Se conecta al servidor proxy.
2. Envía una solicitud HTTP CONNECT para abrir un túnel al extremo OTLP New Relic.
3. Realiza un protocolo de enlace TLS con el extremo OTLP a través de ese túnel.
4. Agrega un encabezado Proxy-Authorization: Basic <base64> si proporcionó credenciales.

Requisitos del servidor proxy

Su servidor proxy debe admitir:

• El método HTTP CONNECT (requerido para la tunelización TLS al extremo OTLP).
• Creando un túnel hacia el puerto 443 (el extremo OTLP usa HTTPS).
• Autenticación básica HTTP, si utiliza acceso proxy autenticado.

Servidores proxy compatibles

Limitaciones de caracteres de las credenciales

Cuando configure las credenciales del proxy, use solo los siguientes caracteres:

• Nombre de usuario: letras minúsculas (a–z), dígitos (0–9), guion (-), guion bajo (_), punto (.) y tilde (~). No se permiten letras mayúsculas.
• Contraseña: letras (a–z, A–Z), dígitos (0–9), guion (-), guion bajo (_), punto (.) y virgulilla (~).

Los siguientes caracteres no están permitidos ni en el nombre de usuario ni en la contraseña: @, :, /, ?, #, [, ], !, $, &, ', (, ), *, +, ,, ;, =, %, espacios y otros caracteres especiales.

Si sus credenciales de proxy existentes utilizan caracteres no permitidos, solicite a su administrador de proxy que cree una cuenta de proxy dedicada para el eBPF agent que utilice un nombre de usuario alfanumérico en minúsculas y una contraseña sencilla.

Precedencia de configuración

Cuando más de un origen define un proxy, el agente los aplica en este orden:

• otlpProxy.url — URL completa del proxy.
• otlpProxy.* — Configuración de proxy individual (host, port, scheme, user, password).

Esta precedencia se aplica tanto al host de Linux como a los despliegues de Kubernetes.

Configurar un proxy

otlpProxy:
  host: "proxy.corporate.com"
  port: 8080
  scheme: "http"
  user: "myuser"
  password: "mypassword"
  url: ""
  existingSecret: ""

$
kubectl create secret generic ebpf-proxy-creds \
>
  --namespace newrelic \
>
  --from-literal=proxy-user=myuser \
>
  --from-literal=proxy-password=mypassword

$
helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yaml

otlpProxy:
  host: "proxy.corporate.com"
  port: 8080
  scheme: "http"
  user: "myuser"
  password: "mypassword"
  url: ""

$
sudo chmod 600 /etc/newrelic-ebpf-agent/newrelic-ebpf-agent.yaml
$
sudo systemctl restart newrelic-ebpf-agent

Verifique la configuración del proxy

Después de configurar el proxy, valide que el agente lo esté utilizando según lo esperado.

Revisar el log del agente

Revise el registro del agente en busca de mensajes relacionados con el proxy:

$
journalctl -u newrelic-ebpf-agent | grep -i proxy

Busque uno de estos mensajes:

• Using proxy for OTLP endpoint: <endpoint> via http://<host>:<port> — El proxy está habilitado.
• Proxy authentication enabled (username: <user>) — La autenticación básica está configurada.
• Direct connection to OTLP endpoint (no proxy configured) — No hay ningún proxy en uso.

Probar la conectividad del proxy

Utilice curl para confirmar que su proxy admite el método HTTP CONNECT y puede llegar al extremo OTLP de New Relic:

$
# Unauthenticated proxy
$
curl -v -x http://proxy.example.com:8080 https://otlp.nr-data.net
$

$
# Authenticated proxy
$
curl -v -x http://user:pass@proxy.example.com:8080 https://otlp.nr-data.net

Una respuesta exitosa incluye:

< HTTP/1.1 200 Connection established
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!

Si el agente no enruta a través del proxy o encuentra errores, consulte Solucionar problemas del proxy de eBPF.

Consideraciones de Seguridad

Cuando enrute el agente a través de un proxy, tenga en cuenta lo siguiente:

• Los datos de telemetría se mantienen cifrados con TLS de extremo a extremo. El proxy solo ve un túnel cifrado al extremo de OTLP. Nunca tiene acceso a sus datos.
• Las credenciales del proxy se envían en texto plano al proxy porque el agente no admite el esquema de proxy https://. Solo use la autenticación de proxy en una red de confianza entre el agente y el proxy. Si necesita transporte cifrado entre el agente y el proxy, ejecute el proxy en localhost o use una VPN.
• El agente nunca escribe contraseñas en sus logs. El nombre de usuario puede aparecer en líneas de log como Proxy authentication enabled (username: <user>) para depuración.
• Los despliegues de Kubernetes deberían usar existingSecret en lugar de credenciales en línea para mantener las contraseñas del proxy fuera de su archivo values.yaml y del control de código fuente.