Configurer un proxy pour l'agent eBPF New Relic

Si votre environnement achemine le trafic sortant via un proxy d'entreprise, vous pouvez configurer le eBPF agent New Relic pour envoyer la télémétrie OTLP via ce proxy. Cette page explique comment configurer la prise en charge du proxy sur les hôtes Linux et les clusters Kubernetes, les exigences du serveur proxy, et comment résoudre les problèmes courants.

Comment fonctionne la prise en charge du proxy

Le eBPF agent utilise la prise en charge intégrée du proxy HTTP de gRPC. Lorsque vous configurez un proxy, l'agent :

1. Se connecte au serveur proxy.
2. Envoie une requête HTTP CONNECT pour ouvrir un tunnel vers le point de terminaison OTLP de New Relic.
3. Effectue une négociation TLS avec le point de terminaison OTLP via ce tunnel.
4. Ajoute un en-tête Proxy-Authorization: Basic <base64> si vous avez fourni des identifiants.

Exigences du serveur proxy

Votre serveur proxy doit prendre en charge :

• La méthode HTTP CONNECT (requise pour le tunneling TLS vers le point de terminaison OTLP).
• Tunneling vers le port 443 (le point de terminaison OTLP utilise HTTPS).
• Authentification de base HTTP, si vous utilisez un accès proxy authentifié.

Serveurs proxy pris en charge

Limitations de caractères des identifiants

Lorsque vous configurez les identifiants du proxy, utilisez uniquement les caractères suivants :

• Nom d'utilisateur : lettres minuscules (a–z), chiffres (0–9), trait d'union (-), trait de soulignement (_), point (.) et tilde (~). Les majuscules ne sont pas autorisées.
• Mot de passe : lettres (a–z, A–Z), chiffres (0–9), trait d’union (-), trait de soulignement (_), point (.) et tilde (~).

Les caractères suivants ne sont pas autorisés dans le nom d’utilisateur ou le mot de passe : @, :, /, ?, #, [, ], !, $, &, ', (, ), *, +, ,, ;, =, %, les espaces et autres caractères spéciaux.

Si vos identifiants de proxy actuels utilisent des caractères non autorisés, demandez à votre administrateur de proxy de créer un compte de proxy dédié pour le eBPF agent qui utilise un nom d'utilisateur alphanumérique en minuscules et un mot de passe simple.

Préséance de configuration

Lorsque plus d'une source définit un proxy, l'agent les applique dans cet ordre :

• otlpProxy.url — URL complète du proxy.
• otlpProxy.* — Paramètres de proxy individuels (host, port, scheme, user, password).

Cette priorité s'applique aux déploiements sur hôte Linux et Kubernetes.

Configurer 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

Vérifiez la configuration de votre proxy

Après avoir configuré le proxy, vérifiez que l'agent l'utilise comme prévu.

Vérifier le log de l'agent

Vérifiez le log de l'agent pour les messages liés au proxy :

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

Recherchez l'un de ces messages :

• Using proxy for OTLP endpoint: <endpoint> via http://<host>:<port> — Le proxy est activé.
• Proxy authentication enabled (username: <user>) — L'authentification de base est configurée.
• Direct connection to OTLP endpoint (no proxy configured) — Aucun proxy n'est utilisé.

Tester la connectivité du proxy

Utilisez curl pour confirmer que votre proxy prend en charge la méthode HTTP CONNECT et peut atteindre le point de terminaison 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

Une réponse réussie inclut :

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

Si l’agent ne passe pas par le proxy ou si vous rencontrez des erreurs, consultez Dépanner le proxy eBPF.

Considérations de sécurité

Lorsque vous acheminez l'agent via un proxy, gardez à l'esprit ce qui suit :

• Les données télémétriques restent chiffrées par TLS de bout en bout. Le proxy ne voit qu'un tunnel chiffré vers le point de terminaison OTLP. Il n'a jamais accès à vos données.
• Les identifiants du proxy sont envoyés en clair au proxy parce que l'agent ne prend pas en charge le schéma de proxy https://. Utilisez l'authentification par proxy uniquement sur un réseau de confiance entre l'agent et le proxy. Si vous avez besoin d'un transport chiffré entre l'agent et le proxy, exécutez le proxy sur localhost ou utilisez un VPN.
• L’agent n’écrit jamais de mots de passe dans ses logs. Le nom d'utilisateur peut apparaître dans des lignes de log telles que Proxy authentication enabled (username: <user>) pour le débogage.
• Les déploiements Kubernetes devraient utiliser existingSecret au lieu d’identifiants en ligne pour conserver les mots de passe de proxy en dehors de votre fichier values.yaml et du contrôle de code source.