Hiding OpenTelemetry UI in n8n: Protecting Sensitive OTEL Headers in Customer-Facing Deployments

Why hiding OTEL settings matters

Telemetry headers and exporter configuration often embed credentials or API keys. Displaying these settings in the UI risks accidental disclosure to users or third parties, increasing the attack surface-particularly for service providers offering managed or customer-facing instances. An environment variable like N8N_HIDE_OPENTELEMETRY_PAGE=true would be a minimal, high-impact mitigation.

Short-term mitigations

If the platform lacks a flag today, consider these operational controls: 1) Move OTEL headers and exporters into a secure secrets store (HashiCorp Vault, cloud secret managers) and inject them only at runtime as environment variables that are not surfaced to the UI. 2) Lock down the OpenTelemetry route/UI using reverse-proxy rules or web server ACLs to restrict access to internal admins. 3) Mask or redact sensitive fields at the application layer if feasible (display placeholders rather than raw keys).

Long-term platform and governance actions

Ask the vendor to add a formal toggle and to enforce UI-level masking of secrets by default. Request RBAC that can limit which users can view telemetry configuration. From a governance perspective, standardize telemetry onboarding: require a secrets manager, rotate exporter keys periodically, and include OTEL configuration checks in security audits.

Recommendations for leaders

Prioritize eliminating secret exposure from UI surfaces in customer deployments: either apply a temporary access control or patch the UI, and file an upstream feature request for a hide-OTEL setting. Combine that with secret management and rotation policies so telemetry is both observable and secure without compromising customer trust or regulatory compliance.