Skip to content

fix: [Connectivity-ZTIS] Deterministic SVID selection - #1246

Open
rpanackal wants to merge 4 commits into
mainfrom
fix/deterministic-svid-selection
Open

fix: [Connectivity-ZTIS] Deterministic SVID selection#1246
rpanackal wants to merge 4 commits into
mainfrom
fix/deterministic-svid-selection

Conversation

@rpanackal

Copy link
Copy Markdown
Member

Fixes

ZeroTrustIdentityService did not configure an svidPicker when building X509SourceOptions, causing java-spiffe-core to fall back to getDefaultSvid() which simply returns the first SVID in an unordered list. When the SPIRE agent returns multiple SVIDs to a workload (e.g., after creating a second service key for the same ZTIS instance, or when a co-located workload has overlapping selectors), this resulted in non-deterministic SVID selection that could silently present the wrong identity during mTLS handshakes.

This change configures an svidPicker that deterministically selects the SVID whose SPIFFE ID matches the expected ID from the ZTIS service binding (credentials.workload.spiffeID), as required by the SPIFFE specification.

Feature scope:

  • Configure svidPicker in ZeroTrustIdentityService.initX509Source() to select SVID by SPIFFE ID
  • Add pickSvid helper method with proper error handling for no-match scenarios
  • Add unit tests covering happy path (single/multiple SVIDs) and error cases
  • Update release notes with bug fix entry

Definition of Done

  • Functionality scope stated & covered
  • Tests cover the scope above
  • Error handling created / updated & covered by the tests above
  • Documentation updated
  • Release notes updated

@rpanackal rpanackal changed the title Fix/deterministic svid selection fix: [Connectivity-ZTIS] Deterministic SVID selection Aug 4, 2026

@Jonas-Isr Jonas-Isr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a minor point and a comment. Looks good to me otherwise :)

@CharlesDuboisSAP CharlesDuboisSAP left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of the test fail when you remove the svidPicker

.filter(svid -> expectedSpiffeId.equals(svid.getSpiffeId()))
.findFirst()
.orElseThrow(
() -> new CloudPlatformException(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why throw? If not found we could use the old behaviour of not setting a svidPicker?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Falling back to the old behavior would reproduce the bug in a smaller scope — it would only behave correctly when there's exactly one SVID, or when the library happens to pick the right one from an unordered list. That's the non-determinism we're fixing.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It only throws when it doesn’t find the svid from the list right?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, just improved the tests to address the other concern regarding removing the svidPicker

rpanackal and others added 2 commits August 4, 2026 14:55
…k/cloudplatform/connectivity/ZeroTrustIdentityService.java

Co-authored-by: Jonas-Isr <jonas.israel@sap.com>
.builder()
.spiffeSocketPath(socketPath)
.initTimeout(DEFAULT_SOCKET_TIMEOUT)
.svidPicker(svids -> pickSvid(svids, expectedSpiffeId))

@CharlesDuboisSAP CharlesDuboisSAP Aug 4, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remove the svidPicker, the tests are still green apart from assertThat(picker).isNotNull();
I don't think any test checks the actual change of this PR, the svidPicker

@Jonas-Isr Jonas-Isr Aug 4, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is the same issue discussed here?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then wdym it's a compromise, if you revert the production code the tests are still green

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants