ZeroTrustIdentityService does not configure svidPicker, causing non-deterministic SVID selection

未关闭
#1,243 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
70/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
java
领域
backend, security

调研方向

从 ZeroTrustIdentityService.initX509Source() 开始,检查 ZTIS 绑定凭据和 X509SourceOptions 的使用方式。确认有多个 SVID 可用时的 SVID 选择行为;完成标准是选择基于 credentials.workload.spiffeID,而不是列表顺序,并且在不存在匹配的 SVID 时明确失败。

由索引模型根据 Issue 内容生成。

描述

bug
Describe the Bug

ZeroTrustIdentityService does not configure svidPicker, causing non-deterministic SVID selection

Library: com.sap.cloud.sdk.cloudplatform:connectivity-ztis
Affected version: 5.32.0 (and likely earlier)
SPIFFE library: io.spiffe:java-spiffe-core:0.8.17


Problem

ZeroTrustIdentityService.initX509Source() builds an X509SourceOptions without setting an svidPicker:

X509SourceOptions.builder()
    .spiffeSocketPath(socketPath)
    .initTimeout(DEFAULT_SOCKET_TIMEOUT)
    .build();  // no .svidPicker(...) → falls back to getDefaultSvid()

DefaultX509Source.setX509Context() (in java-spiffe-core) then falls back to getDefaultSvid(), which simply returns the first SVID in the list:

if (picker == null) {
    svidUpdate = update.getDefaultSvid();   // first in list — non-deterministic
} else {
    svidUpdate = picker.apply(update.getX509Svids());
}

The SPIRE agent does not guarantee ordering. The set of SVIDs served for a workload changes when:

  • A new CF service key is created for the ZTIS service instance — the ZTIS service broker registers a new SPIRE workload entry with the same selectors (CF space/app), making it visible to the running sidecar.
  • Another service on the same Diego cell has a workload entry with overlapping selectors.

When this happens, getDefaultSvid() silently returns a different SVID — one belonging to another service key or workload. The mTLS handshake then either fails or presents the wrong identity to the remote service.


// Desired behaviour inside ZeroTrustIdentityService
String expectedSpiffeId = binding.getCredentials().get("workload.spiffeID");

X509SourceOptions.builder()
    .spiffeSocketPath(socketPath)
    .initTimeout(DEFAULT_SOCKET_TIMEOUT)
    .svidPicker(svids -> svids.stream()
        .filter(s -> s.getSpiffeId().toString().equals(expectedSpiffeId))
        .findFirst()
        .orElseThrow(() -> new IllegalStateException(
            "No SVID found for SPIFFE ID: " + expectedSpiffeId)))
    .build();

Impact

  • Silent mTLS identity mismatch — the wrong certificate is presented to the remote service with no warning.
  • Failures are transient and environment-dependent: they only reproduce after a new service key is created or a co-located workload registers overlapping selectors, making them hard to diagnose.
  • Workaround requires consumers to bypass ZeroTrustIdentityService entirely and manage the X509Source lifecycle themselves.

Suggested Fix

Read credentials.workload.spiffeID from the ZTIS binding (already available in the binding credentials) and pass it as the svidPicker predicate to X509SourceOptions. This is a non-breaking addition — the picker only applies when multiple SVIDs are present; when only one SVID is served, the predicate still matches correctly.

No new dependencies are required; io.spiffe is already a transitive dependency of connectivity-ztis.


Environment

Component Version
connectivity-ztis 5.32.0
java-spiffe-core 0.8.17
Runtime SAP BTP Cloud Foundry (Diego cell)
Java 21
Steps to Reproduce

Steps to Reproduce

  1. Deploy a CF application using ZeroTrustIdentityService for mTLS.
  2. Create a second CF service key for the same ZTIS service instance.
  3. Observe that getDefaultSvid() may now return the SVID from the new service key rather than the application's own SVID.
  4. The mTLS handshake with the remote service fails or presents the wrong identity.
Expected Behavior

Expected Behaviour

The X509SourceOptions should be built with an svidPicker that selects the SVID matching the SPIFFE ID from the ZTIS service binding credentials (credentials.workload.spiffeID). The SPIFFE spec explicitly requires that workload API clients select SVIDs by their known SPIFFE ID; accepting the first arbitrarily is a misuse of the Workload API.

Screenshots

No response

Used Versions
  • Java and Maven version via mvn --version: ...
  • SAP Cloud SDK version: ...
  • Spring Boot or CAP version: ...
Dependency tree via mvn dependency:tree
Dependency tree here
Code Examples
// Your code here
Stack Trace

No response

Log File
Log file ...
Affected Development Phase

Getting Started

Impact

No Impact

Timeline

No response

主要语言
Java
星标
41
派生
33
平均合并
18 小时 34 分钟
30 天内合并 PR
19

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

SAP/cloud-sdk-java 的其他 Issue

查看 SAP/cloud-sdk-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。