Conversation
|
|
||
| // values defines the values of the HTTP header. | ||
| // | ||
| // +kubebuilder:validation:MinItems=1 |
There was a problem hiding this comment.
| // +kubebuilder:validation:MinItems=1 | |
| // +kubebuilder:validation:MinItems=1 | |
| // +kubebuilder:validation:items:MinLength=1 |
There was a problem hiding this comment.
Applied in 2079ca2b8 — thanks. items:MinLength=1 matches the existing convention in prometheus_types.go, probe_types.go and scrapeconfig_types.go, so the rendered schema now has items: {minLength: 1, type: string} alongside the existing minItems: 1.
| // | ||
| // It requires Prometheus >= v2.55.0. | ||
| // | ||
| // +listType=map |
There was a problem hiding this comment.
| // +listType=map | |
| // +kubebuilder:validation:MinItems=1 | |
| // +listType=map |
There was a problem hiding this comment.
Applied in 2079ca2b8, and I added the same MinItems=1 to Endpoint.HTTPHeaders in types.go as well — the ServiceMonitor field is identical, and marking only PodMetricsEndpoint would have left the two CRDs with different validation. Regenerated artifacts are in the same commit (CRDs, jsonnet, bundle.yaml); api.md is unchanged because that generator doesn't render validation constraints.
One thing I left out deliberately: HTTPHeader.Validate() rejects an empty values list but doesn't check for empty strings, so semantic validation is now slightly looser than the schema. Happy to tighten it if you'd like, but I kept this commit scoped to the markers.
|
it needs a rebase. |
2079ca2 to
977c2a0
Compare
Prometheus supports custom HTTP headers in scrape configurations since v2.55.0 but the operator had no way to set them for ServiceMonitor and PodMonitor endpoints. Header names which are managed by Prometheus itself are rejected during the resource selection, using the reserved list from prometheus/common. Fixes prometheus-operator#7189 Signed-off-by: somaz <genius5711@gmail.com>
Signed-off-by: somaz <genius5711@gmail.com>
977c2a0 to
42ff3a9
Compare
|
Rebased onto main, no conflicts. Thanks! |
|
Test need to be fixed |
|
That test doesn't touch anything this PR changes — the diff is ServiceMonitor/PodMonitor only, with no alertmanager paths — and the same job passed on this branch five hours earlier in run 33826114913. In the failing run 54 of the 55 alertmanager subtests passed, and the job has failed on three unrelated branches this week (a dependabot bump, the msteams e2e case, the global-config e2e case), each time on a different subtest with a context deadline. That reads like a timing flake rather than a regression from this change. Could you re-run it? I can't trigger a re-run from the fork, and I'd rather not push a no-op commit if it's avoidable. |
|
Thanks for doing this and sorry in advance for the late reply. Storing header values directly into the custom resources poses a security risk since users may accidentally leak sensitive data (e.g. API keys) into them. Though the risk is low, it exists (Prometheus supports both clear-text, file and secret values) and I'd prefer that we adopt a safe approach by using secret key references. |
|
Makes sense. Prometheus's own |
Description
Prometheus supports
http_headersin scrape configurations since v2.55.0, but there was no way to set them from a ServiceMonitor or a PodMonitor.This adds an
httpHeadersfield to the ServiceMonitor endpoints and the PodMonitor pod metrics endpoints. Only plainvaluesare supported for now,secretsandfilescan be added later as optional fields without breaking the API. Header names reserved by Prometheus (Authorization,Host, ...) are rejected during the resource selection, reusingconfig.ReservedHeadersfrom prometheus/common.For context: #7003 added
http_headerstooauth2,remote_read,remote_writeand ScrapeConfig, but not to the ServiceMonitor/PodMonitor endpoints this issue is about. Probe and ScrapeConfig endpoints can follow the same pattern in separate pull requests.Closes: #7189
Type of change
FEATURE(non-breaking change which adds functionality)Verification
make generate,make checkandmake test-unitpass locally.New unit tests:
TestServiceMonitorEndpointHTTPHeadersandTestPodMonitorEndpointHTTPHeaderswith golden files for v2.55.0 (rendered) and v2.54.0 (dropped with a warning).TestSelectServiceMonitorsandTestSelectPodMonitorsfor a valid header, a reserved header name and a header without value.No end-to-end test since the change only affects configuration generation, which the golden files cover.
Changelog entry
Generative AI (Claude Code) was used to write parts of this change. I reviewed and tested it myself.