1. 从一次安全扫描告警说起Eureka未授权访问的普遍性与紧迫性最近在给一个基于Spring Cloud的微服务项目做安全加固安全扫描工具毫不意外地又报了一个“Spring Eureka Server 未授权访问漏洞”。说实话这个漏洞在内部系统、测试环境里太常见了以至于很多开发者都习以为常觉得“反正内网访问问题不大”。但恰恰是这种心态埋下了巨大的安全隐患。这个漏洞的本质是Eureka的服务注册与发现端点比如/eureka/apps暴露在了公网或者对内部所有人员开放导致任何能访问到该地址的人无需任何认证就能直接获取到整个微服务集群的拓扑信息包括所有注册上来的服务实例IP、端口、健康状态甚至是服务实例的元数据metadata。想象一下攻击者拿到这份“服务地图”后可以精准地对每一个服务实例发起攻击其危害性不言而喻。这个漏洞的修复远不止是加个密码那么简单。它涉及到对Spring Security的集成、对Eureka Server和Client配置的联动调整以及在云原生环境下如何与现有认证体系如OAuth2、JWT结合。网上很多教程只给片段代码照着做常常会遇到Client注册不上、Security配置冲突、健康检查失败等一系列问题。今天我就结合自己多次踩坑和修复的经验从漏洞原理、修复方案选型、到一步步的实操配置和避坑指南为你完整梳理一遍。无论你是刚接手一个老项目还是正在搭建新的微服务架构这篇文章都能帮你彻底解决这个安全问题。2. 漏洞深度剖析为什么你的Eureka“门户大开”在动手修复之前我们必须先搞清楚漏洞产生的根源和潜在风险这样才能理解后续每一个配置步骤的必要性。2.1 Eureka Server的端点暴露机制Eureka Server本身是一个Spring Boot应用它通过一系列REST端点对外提供服务。核心端点包括服务注册POST /eureka/apps/{APP-ID}服务发现GET /eureka/appsGET /eureka/apps/{APP-ID}服务续约PUT /eureka/apps/{APP-ID}/{INSTANCE-ID}服务下线DELETE /eureka/apps/{APP-ID}/{INSTANCE-ID}管理端点POST /eureka/statusPUT /eureka/status等。默认情况下Spring Boot Actuator的管理端点如/actuator/health,/actuator/info可能因为版本或配置不当也一同暴露这同样是高风险点参考网络热词中的“springboot actuator 未授权访问漏洞”。Eureka Server启动后这些端点如果没有受到任何安全框架的保护就会处于“裸奔”状态。2.2 未授权访问带来的具体风险获取到服务注册信息只是第一步攻击者可以利用这些信息进行更深层次的攻击服务发现与侦察绘制完整的系统架构图了解后端服务的技术栈通过metadata判断、网络布局。直接服务攻击知道了每个服务的IP和端口攻击者可以绕过网关直接对内部服务发起SSRF、API攻击或尝试利用已知的组件漏洞如Fastjson RCE参考热词。服务伪装与中间人攻击通过伪造一个恶意的服务实例注册到Eureka将流量引导至攻击者控制的服务器窃取或篡改数据。拒绝服务攻击通过频繁调用注册、下线接口干扰Eureka Server的正常工作或向特定服务实例发送大量垃圾请求。2.3 与类似组件的对比这个漏洞和“zookeeper未授权漏洞”、“Redis未授权访问”等在本质上是一样的一个本该受控的核心基础设施组件因为缺乏最基本的认证授权导致整个系统的边界被突破。修复思路也相通要么网络隔离如绑定内网IP、使用安全组要么添加访问控制。对于Eureka由于其HTTP RESTful的特性集成Spring Security是最自然、最Spring的方式。3. 修复方案选型从基础认证到整合云原生安全方案没有最好只有最适合。我们需要根据项目阶段、运维复杂度和整体安全架构来选择。3.1 方案一集成Spring Security进行HTTP Basic认证这是最经典、最直接的修复方案适用于大多数中小型项目或内部系统。其原理是在Eureka Server端添加一个Spring Security的过滤器链对访问/eureka/**路径的请求进行HTTP Basic认证。优点实现简单添加依赖写少量配置即可。与Spring生态无缝集成配置方式非常“Spring”。客户端配置明确在Client的配置文件中直接写入用户名密码。缺点密码硬编码用户名密码通常写在配置文件中安全性依赖配置文件本身的保密性。静态凭证不易实现动态的凭证管理和轮换。粒度较粗通常是全局认证难以实现更细粒度的角色权限控制虽然可以做到但较复杂。3.2 方案二整合OAuth2或JWT进行令牌认证适用于已经拥有统一认证授权中心如Keycloak、Okta、自研OAuth2服务器的中大型项目。Eureka Server作为一个资源服务器验证Client携带的Bearer Token。优点动态安全令牌可过期、可吊销安全性更高。统一认证与系统其他服务共用一套认证体系。避免密码泄露客户端不保存密码只保存有时效性的token或使用client_credentials流程获取token。缺点实现复杂需要搭建或接入认证服务器配置复杂度高。客户端逻辑变重客户端需要先获取token再携带token进行注册/心跳。依赖外部服务Eureka Server和Client的可用性依赖于认证服务的可用性。3.3 方案三网络层隔离严格来说这不是“修复”漏洞而是“规避”风险。通过防火墙、安全组、Kubernetes NetworkPolicy等将Eureka Server的访问权限限制在仅允许可信的微服务客户端IP或Pod访问。优点彻底从网络根源上杜绝外部访问。无代码侵入不需要修改任何应用配置。缺点运维复杂在动态伸缩的云环境或容器平台中维护精准的IP白名单挑战很大。不灵活不利于跨网络环境如开发、测试的复用。无法防止内部威胁如果攻击者已经进入内网此方案失效。结论与选型建议 对于绝大多数需要快速、有效修复漏洞的场景方案一HTTP Basic认证是首选。它平衡了安全性、复杂度和可维护性。下文将以此方案为核心展开详细配置。同时我也会在关键节点指出如果你未来需要升级到方案二OAuth2需要注意哪些地方。4. 手把手修复为Eureka Server穿上Spring Security的“铠甲”我们假设你有一个正在运行的、未加密的Eureka Server。下面一步步为其添加安全防护。4.1 第一步修改Eureka Server的依赖与配置首先找到你的Eureka Server项目通常是一个独立的Spring Boot应用主类上标有EnableEurekaServer。1. 添加Spring Security依赖在pom.xml中添加依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency注意这里添加的是spring-boot-starter-security它会自动引入Spring Security的核心功能。无需单独指定版本由Spring Boot的Parent或BOM管理即可。2. 配置Eureka Server的application.yml关键配置在于eureka.client部分。因为现在Server自己也需要向自己或集群中的其他Server注册和获取注册表所以它本身也是一个Client。我们需要为这个“内置Client”配置认证信息。server: port: 8761 spring: application: name: eureka-server # Spring Security配置设置一个默认的用户名和密码。 # 注意这只是一个简单示例生产环境应从安全配置服务器或环境变量读取。 security: user: name: admin password: eurekasecret2024 eureka: instance: hostname: localhost client: # 禁止从对等节点获取注册表单机模式 fetch-registry: false # 禁止向对等节点注册自己单机模式 register-with-eureka: false # 指向自己并且带上安全认证信息 service-url: defaultZone: http://admin:eurekasecret2024localhost:8761/eureka/重点解读spring.security.user.name/password这里定义了访问该Spring Boot应用所有端点的默认HTTP Basic认证凭据。也就是说现在访问http://localhost:8761的任何路径都需要输入这个用户名密码。eureka.client.service-url.defaultZone这是最易出错的一步。Eureka Server在启动时会作为一个Client尝试向defaultZone指定的地址注册。现在这个地址受保护了所以必须在URL中直接嵌入认证信息格式为http://username:passwordhost:port/eureka/。很多同学修复后Server启动报“无法连接”错误问题就出在这里。3. 自定义安全配置类关键步骤默认情况下Spring Security会保护所有端点。但Eureka Server的Dashboard前端那些CSS、JS文件和Eureka Client用于心跳的端点需要被特殊处理。我们需要一个配置类来细化安全规则。import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter; EnableWebSecurity public class WebSecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { // 关键配置对Eureka的端点进行认证同时放行一些静态资源。 http.csrf().disable() // Eureka Client默认不发送CSRF token需要禁用 .authorizeRequests() .antMatchers(/eureka/**).hasRole(USER) // 保护/eureka下所有端点 .antMatchers(/actuator/**).hasRole(ADMIN) // 强烈建议保护Actuator端点 .anyRequest().authenticated() // 其他所有请求都需要认证 .and() .httpBasic(); // 使用HTTP Basic认证方式 } }为什么这么做csrf().disable()这是必须的。Eureka Client发送的HTTP请求如心跳PUT请求不会携带CSRF令牌如果不关闭会导致Client无法续约。.antMatchers(/eureka/**).hasRole(USER)指定所有Eureka REST API端点都需要拥有ROLE_USER角色才能访问。我们之前配置的spring.security.user默认就拥有这个角色。.antMatchers(/actuator/**).hasRole(ADMIN)这是一个非常重要的安全加固点。Actuator端点可能泄露敏感信息如/actuator/env暴露所有配置必须用更强的角色如ADMIN保护并与Eureka的普通用户区分开。.httpBasic()启用HTTP Basic认证。这是一种简单但有效的认证方式适合机器对机器的通信如Client对Server。4.2 第二步调整所有Eureka Client的配置Server端保护起来了所有的Client即你的各个微服务应用在注册和心跳时也必须提供正确的凭据。在你的每个微服务应用的application.yml中修改Eureka Client配置eureka: client: service-url: defaultZone: http://admin:eurekasecret2024localhost:8761/eureka/ instance: # 可选但推荐在注册信息中不显示主机名使用IP避免某些网络环境下的解析问题 prefer-ip-address: true核心改动同样是defaultZone现在必须包含用户名和密码。格式与Server中配置自己的URL一致。4.3 第三步启动测试与验证启动Eureka Server访问http://localhost:8761此时浏览器会弹出一个HTTP Basic认证的对话框。输入admin和eurekasecret2024后才能看到熟悉的Eureka Dashboard。启动一个Client应用观察Client的启动日志。你应该能看到类似DiscoveryClient_XXX - registration status: 204的成功信息。如果看到401或403错误请检查Client配置中的用户名密码是否与Server配置一致以及Server的安全配置类是否正确放行了相关路径。在Dashboard中验证登录Dashboard后你应该能看到刚刚启动的Client应用已经成功注册上来。验证未授权访问已被阻断打开一个无痕浏览器或使用curl命令直接访问http://localhost:8761/eureka/apps此时应该返回401 Unauthorized而不是一串XML/JSON格式的服务列表。5. 生产环境进阶配置与避坑指南上面的步骤能解决基本问题但要上生产环境还有一堆坑等着你。5.1 避坑一密码硬编码与安全管理把密码写在application.yml里是极不安全的。生产环境必须使用外部化配置。推荐做法使用环境变量eureka: client: service-url: defaultZone: http://${EUREKA_USER:admin}:${EUREKA_PASSWORD:}${EUREKA_HOST:localhost}:${EUREKA_PORT:8761}/eureka/启动时传入java -jar app.jar -DEUREKA_PASSWORDyourStrongPassword使用配置中心如果项目使用了Spring Cloud Config, Nacos, Apollo等将密码存储在配置中心并确保配置中心本身的安全。使用加密配置Spring Cloud提供了加密配置的功能需配合JCE可以将配置中的密码加密存储。5.2 避坑二Eureka Server高可用集群的配置在集群模式下每个Eureka Server节点既是Server也是Client会相互注册。安全配置需要做相应调整。假设有两个节点peer1 (8761), peer2 (8762)。peer1的配置示例spring: security: user: name: admin password: eurekasecret2024 eureka: client: service-url: # 指向另一个节点并携带认证信息 defaultZone: http://admin:eurekasecret2024peer2:8762/eureka/peer2的配置示例spring: security: user: name: admin password: eurekasecret2024 # 密码必须一致 eureka: client: service-url: defaultZone: http://admin:eurekasecret2024peer1:8761/eureka/关键点集群中所有节点的认证用户名和密码必须一致否则它们将无法相互认证和同步注册表。5.3 避坑三与Spring Cloud Gateway、Feign等组件的兼容性当你使用了Gateway做路由或者服务间使用Feign调用时Eureka返回的服务实例地址是带有http://user:passhost:port格式的。Gateway或Feign在向这个地址发起请求时可能会因为包含了认证信息而出错。解决方案在Eureka Server端我们保护的是/eureka/**端点而不是服务实例自身的业务端点。因此Eureka Client在注册时不应该在eureka.instance.homePageUrl或statusPageUrl等字段中携带认证信息。这些字段默认会从eureka.client.service-url派生但我们需要确保它们指向的是服务实例真实的、无认证信息的业务地址。通常只要保证eureka.client.service-url.defaultZone用于注册发现而服务实例自身的网络策略如Kubernetes Service, Ingress来保证业务端点的安全两者分离就不会有问题。5.4 避坑四健康检查与安全配置的冲突如果你的微服务使用了Spring Boot Actuator并且Eureka Server通过Actuator的/actuator/health端点来检查客户端状态那么你需要确保这个健康检查端点能被Eureka Server访问到。在我们的安全配置类WebSecurityConfig中我们已经将/actuator/**保护了起来要求ADMIN角色。Eureka Server作为另一个服务显然没有这个角色的凭据。解决方案方案A推荐将健康检查端点的安全规则放宽。可以单独为/actuator/health设置免认证或使用一个公开的、低权限的角色。http.authorizeRequests() .antMatchers(/actuator/health).permitAll() // 健康检查端点放行 .antMatchers(/actuator/info).permitAll() // info端点通常也可放行 .antMatchers(/actuator/**).hasRole(ADMIN) // 其他敏感端点严格保护 .antMatchers(/eureka/**).hasRole(USER) .anyRequest().authenticated();方案B在Client端配置Eureka使用一个不带认证的、专门用于健康检查的端点如果存在的话但这需要自定义健康检查逻辑较复杂。5.5 未来演进如何平滑升级到OAuth2保护如果你的系统后续要接入统一的OAuth2认证Eureka的安全体系也可以平滑升级。Server端改造将WebSecurityConfig中的.httpBasic()替换为.oauth2ResourceServer()配置并指定JWT解码器等。Client端改造这是难点。Eureka Client原生不支持在注册请求中自动携带OAuth2 Token。你需要实现一个自定义的DiscoveryClientOptionalArgs配置注入一个带有LoadBalanced和OAuth2拦截器的RestTemplate或WebClient用于与Eureka Server通信。或者更常见的做法是在网络层解决。例如在Kubernetes中可以通过Service Account和Projected Volume使Pod内自动挂载有效Token然后通过一个Sidecar代理如Envoy在请求Eureka Server时自动注入Token。这超出了Spring应用本身的范围属于基础设施安全层。对于大部分项目而言完善的HTTP Basic认证加上严格的网络隔离如Kubernetes NetworkPolicy已经能够提供足够的安全保障。修复漏洞的核心在于建立“最小权限”和“零信任”的意识为每一个暴露的端点都思考其访问控制策略而不是简单地一开了之。这次对Eureka的加固正是这种安全实践的一个具体体现。