Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,243 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
70/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java
Lĩnh vực
backend, security

Hướng nghiên cứu

Bắt đầu tại ZeroTrustIdentityService.initX509Source() và kiểm tra cách các thông tin xác thực binding của ZTIS và X509SourceOptions được sử dụng. Xác nhận hành vi lựa chọn SVID khi có nhiều SVID; hoàn thành có nghĩa là việc lựa chọn dựa trên credentials.workload.spiffeID thay vì thứ tự trong danh sách, với lỗi rõ ràng khi không có SVID nào khớp.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Java
Star
41
Fork
33
Merge trung bình
1 ngày 57 phút
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SAP/cloud-sdk-java

Tất cả issue của SAP/cloud-sdk-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.