Netdata 的 OTLP 端点如何防止未授权的指标和日志接入【免费下载链接】netdataThe fastest path to AI-powered full stack observability, even for lean teams.项目地址: https://gitcode.com/GitHub_Trending/ne/netdataNetdata Agent 的 OTLP/gRPC 端点会接收任何到达该端点的指标和日志数据它自身不做发送方身份校验——安全边界在传输层端点监听在哪里、是否启用 TLS、以及网络访问控制。当 Agent 需要接收其他主机或集群发来的 OTLP 数据时需要按下面这条路径把未授权发送方挡在端口之外。前提条件是 Agent 带有 OpenTelemetry 插件Linux 原生 DEB/RPM 包把它作为netdata的依赖安装静态构建默认包含32 位 ARMv6 构建除外所有 Docker 镜像都包含Linux 源码构建需要--enable-plugin-otel。该插件在 Windows 和 FreeBSD 上不可用。插件随 Agent 自动启动只接受 OTLP/gRPC端口4317不支持otlp_http导出器和 OTLP/HTTP 端口4318。默认回环监听时先判断本机是否可信插件默认监听127.0.0.1:4317只有同一台主机上的进程能连到它网络路径上不需要 TLS。但回环地址只限制可达范围不限制身份本机任何进程都能向端点发送记录开启租户选择后甚至可以指定任意租户。文档给出的判断是主机上每个本地进程都可信时例如一台只运行一个 Collector 并转发到本地 Agent 的节点保持默认监听即可共享主机上在回环监听器上启用带客户端证书的 TLS见下文配置或用主机防火墙限制哪些本地用户能连接该端口netfilter 的ownermatch。接受远程发送方只在 TLS 保护下绑定非回环地址需要让其他主机发送数据时用edit-config编辑otel.yamlcd /etc/netdata 2/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config otel.yamlSecuring the OTLP Endpoint 给出的远程接入配置其中tls_ca_cert_path开启相互认证mutual TLSendpoint: path: 0.0.0.0:4317 tls_cert_path: /etc/netdata/ssl/server-cert.pem tls_key_path: /etc/netdata/ssl/server-key.pem # Require client certificates (mutual TLS): senders must present a # certificate signed by this CA. tls_ca_cert_path: /etc/netdata/ssl/client-ca.pem三个路径的适用条件以 OpenTelemetry 插件参考 为准endpoint.pathAgent 监听的 OTLP/gRPC 端点默认127.0.0.1:4317endpoint.tls_cert_path与endpoint.tls_key_path服务器 TLS 证书与私钥需同时设置endpoint.tls_ca_cert_pathCA 证书路径。设置它即开启 mutual TLS因此也要求服务器证书和私钥已就位客户端必须出示该 CA 签发的证书。文档同时给出四条硬性要求绝不在回环之外暴露明文监听器用防火墙、安全组等网络访问控制把端口4317限制到已知发送方地址——端点只讲 OTLP/gRPC服务器证书从基础设施已经信任的来源签发内部 CA 或证书自动化发送方配置对应的ca_filemutual TLS 下还要配置自己的客户端证书和私钥替换证书后重启 Netdata Agent 才会加载新文件。发送方 Collector 的对应 exporter 配置示例来自 Collect Logs with OpenTelemetry Collector其中logs.example.com和X-Scope-OrgID: production是文档示例值替换为你自己的接收端点地址与租户名mutual TLS 时取消cert_file/key_file两行的注释extensions: file_storage/netdata: directory: /var/lib/otelcol/netdata create_directory: true exporters: otlp_grpc/netdata: endpoint: logs.example.com:4317 tls: ca_file: /etc/otelcol/netdata-ca.pem # For mutual TLS, add the client certificate and key: # cert_file: /etc/otelcol/client-cert.pem # key_file: /etc/otelcol/client-key.pem headers: X-Scope-OrgID: production sending_queue: storage: file_storage/netdata service: extensions: [file_storage/netdata]租户选择只决定存到哪不是身份认证在otel.yaml中开启租户选择auth: enabled: true它的效果与边界每个日志和 trace 发送方必须设置X-Scope-OrgIDgRPC 头没有该头的请求会被拒绝指标不参与租户划分metrics are not tenant-scoped对指标的访问控制完全依赖上一节的监听地址、TLS 和网络限制租户头只选择租户——即对应的存储树和保留策略——不验证发送方身份任何通过 TLS 的客户端都可以声称任意租户。插件参考文档对auth.enabled的措辞是这是租户选择不是凭据认证启用后只应在 TLS 或 mutual TLS 以及合适的网络控制之后信任该头。谁能发送必须由 mutual TLS 和网络控制决定租户只当作组织工具使用例如按团队、环境或系统各给一套保留策略。验证配置已生效、数据被正确接收重启 Agent 后先确认配置被加载。otel.yaml采用严格校验未知 YAML 字段、未知NETDATA_OTEL_CFG_*变量、格式错误的值都会阻止插件启动。在 Agent journal 中查找otel.yaml校验错误systemd 主机上可以用下面的命令查看插件最近的消息journalctl SYSLOG_IDENTIFIERotel-plugin SYSLOG_IDENTIFIERotel-plugin/ingestor --since -10 min插件启动时会记录生效的配置其中remote_storage.uri在日志中被隐去。一次成功的 TCP 连接只能证明有进程在监听不等于数据被接收。在 Netdata 中打开节点的 Metrics tab搜索otel.system.cpu.time、otel.system.memory.usage之类的 context确认图表有真实数据。日志则在 Logs tab 选择otel-logs数据源用Services选择器查看对应服务该视图有访问控制验证日志需要一个已登录该 Agent Space 的 Netdata Cloud 用户。开启租户选择后未带X-Scope-OrgID头的日志和 trace 请求会被拒绝可以用这一点确认头校验已生效。数据落在哪里接收到的遥测数据存储在 Agent 本机不存入 Netdata Cloud。通过 Netdata Cloud 查看日志时内容加密传输到浏览器且不在 Netdata Cloud 上存储查看权限由 Agent Space 的登录用户控制。上线前检查清单端点只绑定到发送方需要的地址明文监听只出现在回环上TLS 服务器证书与私钥就位网络不可信时启用 mutual TLS端口4317已限制到已知发送方地址不同发送方分组需要独立保留策略时已开启租户选择有证书轮换后重启 Agent 的流程租户保留策略与对象存储卸载的配置见 Log Storage and Retention端点行为与接收流程的完整说明见 Securing the OTLP Endpoint 和 Ingest OpenTelemetry Metrics and Logs。【免费下载链接】netdataThe fastest path to AI-powered full stack observability, even for lean teams.项目地址: https://gitcode.com/GitHub_Trending/ne/netdata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考