Elastic Agent与Fleet Server通信流程及认证机制技术问题咨询

核心通信工作流总览 #

二者的全生命周期通信分为两个独立阶段：

• 注册阶段：Agent首次启动后，完成身份校验、拉取初始配置、获取专属访问凭证
• 运行阶段：长连接保持，双向交互配置更新、采集数据、控制指令、状态上报

1. 通信协议选型及设计原因 #

Elastic Stack 7.14及之后的正式版本，二者通信统一采用基于TLS 1.2+加密的HTTP/2承载的gRPC协议，7.13及更早的Beta版本曾短暂使用WebSocket，目前已完全弃用，WebHook从未用于二者的通信链路（仅用于Fleet Server对接外部第三方系统）。
选用gRPC协议的核心原因：

• 原生支持双向流式RPC：可实现Fleet Server主动向Agent推送配置更新、排查任务等指令，无需Agent高频轮询，在10万级Agent大规模部署场景下，服务器侧压力比轮询方案低70%以上
• 序列化效率优势明显：gRPC默认采用Protocol Buffers做序列化，相同数据量下报文体积比JSON小40%左右，编解码速度快2~3倍，特别适配边缘节点、低带宽的部署场景
• 基础能力封装完善：gRPC原生内置连接保活、超时重试、流量控制、多路复用能力，无需上层业务重复开发维护逻辑，官方压测显示10万Agent并发接入时，gRPC方案的服务器资源占用比WebSocket方案低40%
• 和Elastic Stack安全体系天然对齐：默认强制TLS端到端加密，支持证书指纹校验、双向TLS认证，符合全栈安全设计规范

2. Service Token 认证实现逻辑 #

首先明确：Service Token本质是Elasticsearch为内置fleet-server服务账号签发的JWT格式凭证，payload中包含权限范围、签发主体、有效期（默认永久有效，仅可在Elasticsearch侧手动作废）等信息。

2.1 首次注册阶段的认证流程 #

• 你安装Agent时传入的--fleet-server-service-token参数值，会被Agent加密暂存到本地内存，首次发起注册请求时，会将该Token放在gRPC请求的Authorization请求头中，格式为Bearer <token值>发送给Fleet Server
• Fleet Server收到请求后不会本地校验Token，会直接将Token转发给关联的Elasticsearch集群做合法性校验，校验内容包括签名是否合法、权限是否匹配、是否已被作废
• Elasticsearch校验通过后，Fleet Server会为当前Agent生成唯一的专属Agent访问密钥、同步对应策略配置、TLS信任锚信息返回给Agent
• 注册完成后，Agent会将专属访问密钥、注册信息加密持久化到本地存储（Linux路径为/opt/Elastic/Agent/fleet.enc，Windows路径为C:\Program Files\Elastic\Agent\fleet.enc），此时内存中的Service Token会被清除，不会持久化存储

2.2 常规通信阶段的凭证使用规则 #

注册完成后的所有日常通信，Agent只会携带注册阶段获取的专属访问密钥做身份校验，不需要再使用Service Token。
只有两种场景会重新用到Service Token：

• Agent本地存储的注册信息损坏、丢失，需要重新向Fleet Server注册时
• Fleet Server集群地址变更，Agent需要重新绑定新的Fleet Server集群时
  此外Service Token作废仅会影响新的Agent注册请求，已经完成注册的Agent的正常通信不会受到任何影响。

内容的提问来源于stack exchange，提问作者Mann Mehta