Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

vandry
Copy link

@vandry vandry commented Sep 7, 2025

This is the first step toward
#702

The feature is not available until the calling code invokes the WithSpiffeSourceFactory HTTPClientOptions, so no behaviour is yet changed. Use of that option will be the subject of a future change to https://github.com/prometheus/prometheus

SPIFFE replaces the usual peer X.509 certificate verification algorithm with its own that checks SPIFFE IDs in URI SANs and checks against different sets of trust roots for different SPIFFE trust domains. Accordingly, none of the other TLS configuration parameters are applicable when SPIFFE is configured and vice versa and this mutual exclusivity is enforced in tls_config.

There are two ways to set which SPIFFE ID should be expected from a scrape endpoint that is using HTTPS and SPIFFE: in the tls_config, and per-request. The former would be expected mainly on static scrape configs that define a single (perhaps replicated) scrape endpoint. For scrape configs with target discovery it is expected that different endpoints would present certificates with different SPIFFE IDs and so the per-request version would be used. It is intended that the peer's expected SPIFFE ID should come from a new special label spiffe_id which would be populated by target discovery. That too will be part of the next change. For the purposes of this library, the per-request peer SPIFFE ID is supplied in the Context accompanying the Request.

This is the first step toward
prometheus#702

The feature is not available until the calling code invokes the
WithSpiffeSourceFactory HTTPClientOptions, so no behaviour is yet changed.
Use of that option will be the subject of a future change to
https://github.com/prometheus/prometheus

SPIFFE replaces the usual peer X.509 certificate verification
algorithm with its own that checks SPIFFE IDs in URI SANs and checks
against different sets of trust roots for different SPIFFE trust domains.
Accordingly, none of the other TLS configuration parameters are applicable
when SPIFFE is configured and vice versa and this mutual exclusivity is
enforced in tls_config.

There are two ways to set which SPIFFE ID should be expected from a
scrape endpoint that is using HTTPS and SPIFFE: in the tls_config, and
per-request. The former would be expected mainly on static scrape configs
that define a single (perhaps replicated) scrape endpoint. For scrape
configs with target discovery it is expected that different endpoints
would present certificates with different SPIFFE IDs and so the
per-request version would be used. It is intended that the peer's
expected SPIFFE ID should come from a new special label __spiffe_id__
which would be populated by target discovery. That too will be part of
the next change. For the purposes of this library, the per-request peer
SPIFFE ID is supplied in the Context accompanying the Request.

Signed-off-by: Kim Vandry <[email protected]>
@vandry
Copy link
Author

vandry commented Sep 8, 2025

It looks like the automatic edits to go.mod want to bump the Go version, presumably because the new go-spiffe dependency requires it. It might make sense for a code owner to bump the Go version separately, then rebase this on top of that, which should get rid of the test failure.

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.

1 participant