Add support for target scraping with SPIFFE#840
Open
vandry wants to merge 1 commit intoprometheus:mainfrom
Open
Add support for target scraping with SPIFFE#840vandry wants to merge 1 commit intoprometheus:mainfrom
vandry wants to merge 1 commit intoprometheus:mainfrom
Conversation
vandry
force-pushed
the
main
branch
2 times, most recently
from
10fce42 to
aad9b1a
Compare
Author
|
It looks like the automatic edits to |
Author
The Go upgrade was done a few days ago in a277468 so this problem has disappeared. I rebased on top of that. |
Merged
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 <vandry@TZoNE.ORG>
Author
|
Ping. Rebased to head. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.