生产级 Java 服务的端到端安全构建 Jib OIDC 与 SQL Server 动态凭证集成实践

DevSecOps

文章字数: 3.8k

阅读时长: 15 分

我们团队最近接手了一个遗留的Java服务，它的部署流程是一场典型的噩梦。CI服务器上运行着一个臃肿的Jenkinsfile，核心逻辑就是调用mvn clean package生成一个近百兆的fat JAR，然后通过一个包含了20多行RUN和COPY指令的Dockerfile来构建镜像。这个过程不仅缓慢、难以缓存，而且最终产出的镜像体积庞大，甚至使用了root用户来运行Java进程。更糟糕的是，数据库密码以明文形式存在于一个Git仓库中的application-prod.properties文件里，只是这个仓库的权限被设为私有。这套体系在今天看来，每一步都充满了安全隐患和效率瓶颈。

我们的第一个任务就是彻底改造这个服务的构建与部署流程，目标是建立一个符合现代DevSecOps理念的、从源码到运行时的全链路安全管道。改造的核心技术栈被锁定在三个关键点上：

容器化构建: 放弃Dockerfile，转向Google的Jib。它能直接从Maven或Gradle构建出高度优化、无守护进程依赖、默认非root用户的分层镜像，实现快速且可复现的构建。
凭证管理: 彻底消除代码库中的任何硬编码凭证。应用部署到Kubernetes后，必须通过一种安全机制在运行时动态获取SQL Server的连接信息。
身份认证: 废除应用内置的、基于密码的简陋用户管理系统，全面转向基于OpenID Connect (OIDC)的单点登录，将身份认证的重任委托给专业的身份提供商(IdP)。

这不仅仅是一次技术升级，更是一场关于安全意识和工程实践的思维转变。整个改造过程并非一帆风順，下面是我们的完整复盘。

第一阶段：用 Jib 重塑镜像构建流程

问题的起点是那个笨拙的Dockerfile。它最大的问题在于无法有效利用Docker的层缓存。每次代码哪怕只改动一个字符，COPY target/my-app.jar app.jar这一层就会失效，导致后续所有层全部重新构建。fat JAR的模式意味着业务代码、依赖库、框架被打包在一起，任何微小的变动都会污染整个应用层。

Jib通过将应用拆分为多个独立的层来解决这个问题：依赖项、资源文件、编译后的类文件。这种精细化的分层策略，使得只有发生变更的层才会被重新构建和推送，极大地提升了CI/CD的效率。

我们的第一步是修改pom.xml，移除旧的dockerfile-maven-plugin，并引入jib-maven-plugin。

<!-- pom.xml -->
<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>3.4.0</version>
    <configuration>
        <!-- 基础镜像选择：Distroless Java 17，这是一个极简的安全基础镜像，仅包含JVM和必要的库 -->
        <from>
            <image>gcr.io/distroless/java17-debian11</image>
        </from>
        <to>
            <!-- 目标镜像仓库地址和标签 -->
            <image>my-registry.example.com/app/my-secure-service</image>
            <tags>
                <tag>${project.version}</tag>
                <tag>latest</tag>
            </tags>
            <!-- 认证信息：推荐在CI/CD环境中使用环境变量或Docker配置文件进行配置 -->
            <!-- 
            <auth>
                <username>${env.REGISTRY_USER}</username>
                <password>${env.REGISTRY_PASSWORD}</password>
            </auth>
            -->
        </to>
        <container>
            <!-- 运行时配置 -->
            <jvmFlags>
                <jvmFlag>-Xms512m</jvmFlag>
                <jvmFlag>-Xmx1024m</jvmFlag>
                <!-- 启用G1 GC并优化 -->
                <jvmFlag>-XX:+UseG1GC</jvmFlag>
                <!-- 关键安全配置：在容器内以非root用户运行 -->
                <user>1001:1001</user>
            </jvmFlags>
            <ports>
                <port>8080</port>
            </ports>
            <!-- 确保构建是可复现的，时间戳固定 -->
            <creationTime>USE_CURRENT_TIMESTAMP</creationTime>
            <appRoot>/app</appRoot>
        </container>
        <extraDirectories>
            <!-- 
              一个常见的坑：如果应用需要额外的配置文件或证书，必须通过这个配置添加。
              比如，连接SQL Server可能需要特定的信任证书。
            -->
            <paths>
                <path>
                    <from>src/main/jib/certs</from>
                    <into>/etc/certs</into>
                </path>
            </paths>
            <permissions>
                <permission>
                    <file>/etc/certs/sqlserver.crt</file>
                    <mode>444</mode> <!-- 只读权限 -->
                </permission>
            </permissions>
        </extraDirectories>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>build</goal> <!-- 或者 'dockerBuild' 用于本地测试, 'build' 用于推送到远程仓库 -->
            </goals>
        </execution>
    </executions>
</plugin>

这段配置解决了几个核心问题：

基础镜像安全: 使用distroless作为基础镜像，它不包含shell或任何不必要的系统工具，显著减小了攻击面。
非Root运行: 通过<user>1001:1001</user>，我们强制应用在容器内以一个低权限用户运行，避免了容器逃逸等一系列高风险安全问题。
可复现性: <creationTime>USE_CURRENT_TIMESTAMP</creationTime>（或者一个固定时间）确保了只要源码和依赖不变，每次构建出的镜像摘要（digest）都是完全一致的。
外部文件处理: 我们的应用需要一个SSL证书来与SQL Server建立加密连接。extraDirectories配置清晰地解决了如何将本地文件打包到镜像特定路径下，并设置正确权限的问题。这是一个在真实项目中经常遇到的细节问题。

执行mvn compile jib:build后，Jib绕过了本地Docker守护进程，直接将构建好的镜像层推送到了我们的私有仓库。CI流水线中的构建时间从原来的5-8分钟缩短到了1-2分钟，对于频繁的提交，这是一个巨大的效率提升。

第二阶段：剥离并外化 SQL Server 凭证

解决了构建阶段的问题，下一个目标是运行时安全，核心是数据库凭证。旧系统将spring.datasource.password明文写在配置文件里，这是绝对不能容忍的。

我们的目标环境是Kubernetes。在K8s中，管理敏感信息的标准做法是使用Secret对象。方案是：将数据库用户名和密码存储在K8s Secret中，然后在应用的Deployment中将这些Secret作为环境变量注入到Pod里。Spring Boot应用则配置为从环境变量读取这些值。

第一步：创建Kubernetes Secret

首先，我们手动（在生产中应由自动化脚本或Vault等工具管理）创建包含数据库凭证的Secret。

# 用户名和密码必须经过Base64编码
$ echo -n 'db_user_prod' | base64
ZGJfdXNlcl9wcm9k
$ echo -n 'S3cr3tP@ssw0rd!' | base64
UzNjcjN0UEBzc3cwcmQh

# 创建secret.yaml文件
cat <<EOF > secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: mssql-credentials
  namespace: my-app-ns
type: Opaque
data:
  DB_USER: ZGJfdXNlcl9wcm9k
  DB_PASSWORD: UzNjcjN0UEBzc3cwcmQh
EOF

# 应用到集群
$ kubectl apply -f secret.yaml

第二步：修改应用配置以读取环境变量

Spring Boot可以非常方便地通过占位符$ {ENV_VAR_NAME}从环境变量中读取配置。我们修改application.yml：

# application.yml
spring:
  datasource:
    url: jdbc:sqlserver://mssql.db.svc.cluster.local:1433;databaseName=appdb;encrypt=true;trustServerCertificate=false;trustStore=/etc/certs/sqlserver.crt;trustStorePassword=your_truststore_password
    username: ${DB_USER}
    password: ${DB_PASSWORD}
    driver-class-name: com.microsoft.sqlserver.jdbc.SQLServerDriver
  # ... 其他配置

这里的url也包含了之前通过Jib添加的SSL证书路径，展示了各个环节的联动。

第三步：在Deployment中注入Secret

最后一步是修改deployment.yaml，将Secret挂载为容器的环境变量。

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-secure-service-deployment
  namespace: my-app-ns
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-secure-service
  template:
    metadata:
      labels:
        app: my-secure-service
    spec:
      containers:
      - name: my-secure-service
        image: my-registry.example.com/app/my-secure-service:1.0.0
        ports:
        - containerPort: 8080
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: mssql-credentials
              key: DB_USER
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mssql-credentials
              key: DB_PASSWORD
        # 健康检查是生产环境的标配
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 5

当Pod启动时，Kubernetes会自动从名为mssql-credentials的Secret中读取DB_USER和DB_PASSWORD的值，并将它们设置为容器的环境变量。Spring Boot应用启动时，会无缝地读取这些变量并成功连接到SQL Server。

至此，我们成功地将凭证从代码库和镜像中彻底剥离，实现了配置与代码的分离。这是一个巨大的安全进步。

第三阶段：集成 OIDC 实现标准化身份认证

应用的旧认证逻辑是一套自研的用户名/密码体系，不仅安全强度堪忧，而且无法与其他系统集成形成单点登录(SSO)。迁移到OIDC是必然选择。我们选择了一个内部搭建的Keycloak作为身份提供商(IdP)。

Spring Security对OAuth2/OIDC提供了极佳的支持。集成过程主要涉及依赖添加、配置以及安全规则的定义。

第一步：添加依赖

在pom.xml中加入spring-boot-starter-oauth2-client。

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

第二步：配置OIDC Provider信息

在application.yml中，我们需要提供连接到IdP所需的信息。同样，敏感的client-secret也必须通过环境变量注入。

# application.yml
spring:
  security:
    oauth2:
      client:
        registration:
          # 'keycloak' 是一个自定义的注册ID
          keycloak:
            provider: keycloak # 对应下面的provider配置
            client-id: my-secure-service-client
            client-secret: ${OIDC_CLIENT_SECRET} # 从环境变量读取
            authorization-grant-type: authorization_code
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
            scope:
              - openid
              - profile
              - email
        provider:
          keycloak:
            # IdP的Issuer URI，Spring Security会自动从这个地址发现所有OIDC端点
            issuer-uri: https://keycloak.example.com/realms/my-realm

issuer-uri是OIDC配置的核心。Spring Security会访问{issuer-uri}/.well-known/openid-configuration来自动获取授权端点、令牌端点、用户信息端点以及用于验证JWT签名的公钥(JWKS)地址等所有元数据。这大大简化了配置工作。

第三步：编写安全配置类和受保护的API

我们需要一个SecurityConfig类来启用并配置OIDC登录。

// SecurityConfig.java
package com.example.secureapp.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.method.configuration.EnableMethodSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;
import static org.springframework.security.config.Customizer.withDefaults;

@Configuration
@EnableWebSecurity
@EnableMethodSecurity(prePostEnabled = true) // 启用@PreAuthorize等注解
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authorize -> authorize
                // actuator的健康检查端点允许匿名访问
                .requestMatchers("/actuator/health/**").permitAll() 
                // 其他所有请求都需要认证
                .anyRequest().authenticated() 
            )
            // 启用OIDC登录流程，使用默认配置
            .oauth2Login(withDefaults())
            // OIDC客户端通常是无状态的，可以禁用CSRF，但需谨慎评估
            .csrf(csrf -> csrf.disable()); 

        return http.build();
    }
}

有了这个配置，任何未经认证的用户访问受保护的资源时，都会被自动重定向到Keycloak的登录页面。登录成功后，Keycloak会将用户重定向回我们的应用，并附带一个授权码。Spring Security会处理后续的令牌交换、验证和会话创建。

为了验证效果，我们创建一个简单的API端点来显示认证后的用户信息。

// UserInfoController.java
package com.example.secureapp.controller;

import org.springframework.http.ResponseEntity;
import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.security.core.annotation.AuthenticationPrincipal;
import org.springframework.security.oauth2.core.oidc.user.OidcUser;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.Map;
import java.util.stream.Collectors;

@RestController
public class UserInfoController {

    /**
     * 获取当前登录用户的OIDC Claims信息
     * 只有认证用户可以访问
     */
    @GetMapping("/api/me")
    public ResponseEntity<Map<String, Object>> getUserInfo(@AuthenticationPrincipal OidcUser principal) {
        if (principal == null) {
            return ResponseEntity.status(401).build();
        }
        // 从OidcUser对象中可以获取所有标准和自定义的claims
        return ResponseEntity.ok(principal.getClaims());
    }

    /**
     * 这是一个需要特定权限(scope)的API
     * OIDC的scope会映射为Spring Security的Authority, 格式为 'SCOPE_scope_name'
     */
    @GetMapping("/api/admin/data")
    @PreAuthorize("hasAuthority('SCOPE_admin_data')")
    public ResponseEntity<Map<String, String>> getAdminData() {
        return ResponseEntity.ok(Map.of("data", "This is sensitive admin data."));
    }
}

这个Controller展示了两种核心用法：

通过@AuthenticationPrincipal注入OidcUser对象，可以直接访问IdP返回的所有用户信息（Claims）。
通过@PreAuthorize注解，可以实现基于OIDC scope的细粒度访问控制。这是一个常见的错误点，很多开发者不知道如何将OIDC的scope与Spring Security的授权机制联系起来。

全景图：串联所有环节

现在，我们将所有部分串联起来，形成一个完整的、自动化的、安全的流程。

graph TD
    A[Developer: git push] --> B{CI/CD Pipeline};
    B -- 1. Trigger --> C[Maven Build];
    C -- 2. Build & Test --> D[Jib: Build Secure Image];
    D -- 3. Push Image --> E[Container Registry];
    B -- 4. Deploy --> F[Kubernetes Cluster];
    F -- 5. Pull Image --> G[Create Pod];
    H[K8s Secret: mssql-credentials] --> G;
    I[K8s Secret: oidc-client-secret] --> G;
    G -- 6. Inject Secrets as ENV --> J[Container Running];
    J -- On Startup --> K[Spring Boot App];
    K -- Reads ENV --> L[Connects to SQL Server];
    M[End User] -- 7. Access App --> J;
    J -- 8. Redirect to IdP --> N[OIDC Provider: Keycloak];
    N -- 9. User Login --> N;
    N -- 10. Redirect back with auth code --> J;
    J -- 11. Exchange code for tokens --> N;
    J -- 12. Validate Tokens & Create Session --> J;
    J -- 13. Serve Protected Content --> M;

    subgraph "Build Phase"
        A; C; D; E;
    end
    subgraph "Deployment & Runtime"
        F; G; H; I; J; K; L;
    end
    subgraph "Authentication Flow"
        M; N;
    end

这个流程图清晰地展示了从代码提交到用户访问的整个生命周期。Jib负责构建不可变且安全的镜像，Kubernetes负责安全地注入运行时配置，而OIDC则保障了应用层面的用户身份安全。三者环环相扣，共同构成了一个健壮的安全体系。

当前方案的局限性与未来迭代方向

尽管当前的改造已经带来了质的飞跃，但从一个资深工程师的务实角度看，它仍有可以提升的空间。

静态凭证的风险: 目前我们使用的Kubernetes Secret是静态的。尽管它比硬编码好得多，但如果Secret泄露，攻击者仍然可以获得长期的数据库访问权限。更理想的模式是采用动态凭证。集成HashiCorp Vault这类工具，让应用在启动时向Vault申请一个有时效性（例如，几小时）的SQL Server凭证。这样即使凭证泄露，其危害也被限制在极短的时间窗口内。
软件供应链的完整性验证: Jib保证了构建过程的可复现性，但它本身并不能保证你拉取的镜像是未经篡改的。在更严格的安全要求下，我们需要对镜像进行签名。CI流水线在推送完镜像后，可以使用Cosign等工具对镜像摘要进行签名，并将签名信息存储在OCI兼容的仓库中。接着，在Kubernetes端部署一个准入控制器（Admission Controller），如Kyverno或Gatekeeper，制定策略，只允许经过验证的、由可信密钥签名的镜像被部署。这构成了软件供应链安全的最后一道防线。
OIDC客户端密钥轮换: client-secret同样是一个需要被妥善管理的敏感信息。当前的方案中它还是一个静态值。生产级的OIDC实现应该支持客户端密钥的定期自动轮换，以进一步降低密钥泄露的风险。

这次改造的终点，恰恰是下一次优化的起点。技术总是在不断演进，尤其是在安全领域，没有一劳永逸的解决方案，只有持续改进的流程和实践。

Jib SQL Server OpenID Connect Security

基于Firestore与阿里云函数计算构建跨云事件驱动架构的Outbox模式实践

2023-11-15 分布式架构

Firestore Python Alibaba Cloud 设计模式事件驱动架构

基于 Flink Axum 与 Dgraph 构建实时图特征计算与服务链路

2023-10-27 数据工程

Apache Flink Axum Dgraph Rust 图计算实时特征