Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Read http headers from file #980

Open
JoniBecker opened this issue Oct 21, 2022 · 7 comments · May be fixed by #989
Open

Feature Request: Read http headers from file #980

JoniBecker opened this issue Oct 21, 2022 · 7 comments · May be fixed by #989

Comments

@JoniBecker
Copy link

JoniBecker commented Oct 21, 2022

Hello everyone,

in our current situation, we want to probe an endpoint that requires the http header "X-Api-Key": "someAPIkeyHere" to be set instead of a bearer token passed the usual way. It would be great if http headers could be read from a file (analogously to how bearer tokens and basic auth passwords can). We do not control the way authentication is handled, but during my last google session regarding this problem, this seemed to be a somewhat frequent way of doing it in some proprietary software.

We are operating under a strict GitOps workflow, so we are deploying the blackbox exporter using the community helm chart for the blackbox exporter. We manage SealedSecrets in Git to produce Secrets on Kubernetes that in turn are mounted into the blackbox exporter and then used as secret files for Basic Auth and/or bearer token files. In our idealised dream world the same mechanism would allow us to properly populate http header fields (or key: value pairs for the header).

In any case, thank you for your hard work. Working with the various prometheus components we have in place in our projects has been a real blast!

Edit: Just for clarification, the current "solution" we see in our case is to generate the whole configmap from a SealedSecret, whose corresponding decrypted Secret would replace the secret config which would get mounted as the config yaml for the container. Sadly this way makes it so that changing anything config-related means rebuilding the sealed secret manually and further diminishes the usefulness of GitOps since the actual configuration of the Blackbox exporter would not be reconstructable for someone with Git access only.

@electron0zero
Copy link
Member

similar feature for http body is PR'ed in #987, happy to review the PR for this :)

@JoniBecker
Copy link
Author

Thanks for bringing this related issue to my attention. I have limited Go knowledge, but from a quick glance it seems to me like it might be easy enough to implement. Not sure if and when I will find the time, but since we are using the Blackbox Exporter in production maybe I can get a couple of hours off work to throw at this. :)

@danteu
Copy link
Contributor

danteu commented Nov 24, 2022

Author of #987 here. I too have need for the feature described here and I'm halfway through writing a proof-of-concept implementation.

My question would be: What should be the file format for the header file described here? My first idea was yaml, but what we actually need is a simple 'key: value' file format to parse into a map[string]string. This, however, would require creating a parser for this file format (similar to what is described here), which seems excessive for this feature. I would value your input on this.

danteu added a commit to danteu/blackbox_exporter that referenced this issue Nov 25, 2022
Resolves prometheus#980

Signed-off-by: Daniel Teunis <[email protected]>
@danteu danteu linked a pull request Nov 25, 2022 that will close this issue
danteu added a commit to danteu/blackbox_exporter that referenced this issue Nov 25, 2022
Resolves prometheus#980

Signed-off-by: Daniel Teunis <[email protected]>
danteu added a commit to danteu/blackbox_exporter that referenced this issue Nov 25, 2022
Resolves prometheus#980

Signed-off-by: Daniel Teunis <[email protected]>
danteu added a commit to danteu/blackbox_exporter that referenced this issue Nov 25, 2022
Resolves prometheus#980

Signed-off-by: Daniel Teunis <[email protected]>
@JoniBecker
Copy link
Author

Hey, sorry for the delayed response. Sadly, I was unable to get back to this earlier. My suggestion would've been to indeed write a simple parser for files containing key:value pairs, as you did. Hopefully, your work will facilitate the creation of a more general solution as hinted at in #989.

@eloo
Copy link

eloo commented Dec 13, 2022

@roidelapluie is there any PR or something we can track?
because in the PR #989 you have mentioned that you are already working on such a feature

thanks

@druanoor
Copy link
Contributor

Is this going to be added at some point? We also need this feature

@shabuddinshaik
Copy link

When this feature will be added?

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 a pull request may close this issue.

6 participants