GKE部署Spring Boot服务时DefaultSecurityFilterChain未加载BearerTokenAuthenticationFilter

核心现象 #

本地运行Java 17 + Spring Boot 3.2.4的OAuth2资源服务器时，DefaultSecurityFilterChain正常包含BearerTokenAuthenticationFilter，携带有效Bearer Token的请求可完成认证；但部署到GCP GKE后，该过滤器未加载，所有请求被标记为匿名认证，最终因权限不足被拒绝。已配置SecurityFilterChain并开启TRACE级日志排查。

可能原因与解决步骤 #

1. 验证GKE环境的配置文件加载正确性 #

• 确认GKE部署时application.properties（或yaml）中的OAuth2资源服务器配置与本地完全一致，重点检查：
  • spring.security.oauth2.resourceserver.jwt.jwk-set-uri或spring.security.oauth2.resourceserver.jwt.issuer-uri的配置值是否准确
  • 若用K8s ConfigMap/Secret挂载配置，检查挂载路径、文件权限是否正常，避免配置文件未被应用读取
• 临时添加配置打印逻辑，验证GKE环境是否正确获取到OAuth2配置：

  @Value("${spring.security.oauth2.resourceserver.jwt.issuer-uri}")
  private String issuerUri;
  
  @PostConstruct
  public void logLoadedConfig() {
      System.out.println("当前加载的Issuer URI: " + issuerUri);
  }
  

2. 检查依赖完整性与排除规则 #

• 确认项目依赖中包含Spring Security OAuth2资源服务器模块，Spring Boot 3.x对应的依赖：

  <!-- Maven -->
  <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
  </dependency>
  

  // Gradle
  implementation 'org.springframework.boot:spring-boot-starter-oauth2-resource-server'
  

• 排查是否存在依赖排除规则，避免意外移除了spring-security-oauth2-resource-server模块，导致相关自动配置类无法生效

3. 确保SecurityFilterChain配置优先级与扫描有效性 #

• 检查AuthConfig类是否在Spring Boot的组件扫描范围内（比如主启动类所在包的子包），避免配置类未被加载
• 若存在多个SecurityFilterChain Bean，按@Order优先级执行，可能导致当前OAuth2配置被覆盖。给filterChain Bean添加@Order(1)确保优先级：

  @Bean
  @Order(1)
  public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
      http.csrf(csrf -> csrf.disable());
      http.authorizeHttpRequests(authorize -> authorize.anyRequest().authenticated())
          .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
      return http.build();
  }
  

4. 确认GKE的Spring Boot环境配置激活状态 #

• 若使用多环境配置（如application-prod.properties），检查GKE部署时是否正确激活了目标环境，避免使用缺失OAuth2配置的默认环境
• 验证启动命令是否指定了正确的配置文件，例如：

  java -jar app.jar --spring.profiles.active=prod
  

5. 对比本地与GKE的TRACE日志差异 #

• 重点查找以下日志内容：
  • OAuth2ResourceServerAutoConfiguration等自动配置类的加载日志，确认是否因配置缺失未触发自动配置
  • BearerTokenAuthenticationFilter的初始化日志，定位过滤器未创建的原因
  • DefaultSecurityFilterChain的构建日志，对比两地的过滤器列表，找出缺失逻辑

6. 排查K8s流量入口的请求头问题 #

• 确认GKE的Ingress/Load Balancer未修改或删除Authorization请求头，避免Spring Security无法识别Bearer Token（该场景概率较低，但需排除）
• 直接在Pod内部调用服务端点，验证服务本身的认证逻辑是否正常，排除外部流量入口的干扰

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