Support for oauth refresh token when scraping targets

1,356 views
Skip to first unread message

soren...@gmail.com

unread,
Nov 22, 2016, 4:20:26 PM11/22/16
to Prometheus Developers
Hi,

I'm looking to scrape an endpoint that requires authentication using an oauth2 access token in the request header. When doing a static scrape, this is supported just fine with the bearer_token/bearer_token_file config options... but only until the access_token expires and needs to be refreshed using a refresh_token (which is the case for OAuth2?).

So...

1) Are there activities towards implementing support oauth refresh token flow?

2) Are there known workarounds for this? A suggestion in the chat was to try to use labels and label rewriting. Without having looked deeply into the suggestion I would think this means exposing the refresh_token (and client_secret) in the web UI config view, which I don't consider acceptable.

3) Are there thoughts on a solution/effort required? I notice patterns looking similar in some of the service discovery options such as <azure_sd_config>. Perhaps this should be thought of as a service discovery option or does it make sense as an extension of the static scrape (it currently does in my mind)?

Thanks

Looking forward to your feedback

Brian Brazil

unread,
Nov 22, 2016, 5:09:02 PM11/22/16
to soren...@gmail.com, Prometheus Developers
On 22 November 2016 at 21:20, <soren...@gmail.com> wrote:
Hi,

I'm looking to scrape an endpoint that requires authentication using an oauth2 access token in the request header. When doing a static scrape, this is supported just fine with the bearer_token/bearer_token_file config options... but only until the access_token expires and needs to be refreshed using a refresh_token (which is the case for OAuth2?).

So...

1) Are there activities towards implementing support oauth refresh token flow?

The expectation is that you'll have some process updating the token in the bearer_token_file as needed.


2) Are there known workarounds for this? A suggestion in the chat was to try to use labels and label rewriting. Without having looked deeply into the suggestion I would think this means exposing the refresh_token (and client_secret) in the web UI config view, which I don't consider acceptable.

Relabelling explicitly doesn't cover auth, so that wouldn't help (and I'm not sure even if it were supported how this would help you).

Brian
 

3) Are there thoughts on a solution/effort required? I notice patterns looking similar in some of the service discovery options such as <azure_sd_config>. Perhaps this should be thought of as a service discovery option or does it make sense as an extension of the static scrape (it currently does in my mind)?

Thanks

Looking forward to your feedback

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.
To post to this group, send email to prometheus-developers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/be787e2b-fa4b-44fd-910e-9a1c6cb9d0bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Søren Krabbe

unread,
Nov 23, 2016, 12:35:06 PM11/23/16
to Prometheus Developers, soren...@gmail.com
Thanks Brian.

I understand. However, I find it a little "backwards" to put the refresh responsibility on a server script of some sort. That script has no way of knowing when it's proactively time to refresh the token. On the other side, the prometheus scrape process itself will know just in time.

So if the expectation is that users place the refresh outside prometheus I would probably think a proxy on the prometheus server to handle the authentication would be better... though not elegant, I think :)

Do you think the project would accept pull requests for something like this?

Søren 

On Tuesday, November 22, 2016 at 11:09:02 PM UTC+1, Brian Brazil wrote:
On 22 November 2016 at 21:20, <soren...@gmail.com> wrote:
Hi,

I'm looking to scrape an endpoint that requires authentication using an oauth2 access token in the request header. When doing a static scrape, this is supported just fine with the bearer_token/bearer_token_file config options... but only until the access_token expires and needs to be refreshed using a refresh_token (which is the case for OAuth2?).

So...

1) Are there activities towards implementing support oauth refresh token flow?

The expectation is that you'll have some process updating the token in the bearer_token_file as needed.


2) Are there known workarounds for this? A suggestion in the chat was to try to use labels and label rewriting. Without having looked deeply into the suggestion I would think this means exposing the refresh_token (and client_secret) in the web UI config view, which I don't consider acceptable.

Relabelling explicitly doesn't cover auth, so that wouldn't help (and I'm not sure even if it were supported how this would help you).

Brian
 

3) Are there thoughts on a solution/effort required? I notice patterns looking similar in some of the service discovery options such as <azure_sd_config>. Perhaps this should be thought of as a service discovery option or does it make sense as an extension of the static scrape (it currently does in my mind)?

Thanks

Looking forward to your feedback

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.
To post to this group, send email to prometheus...@googlegroups.com.



--

Brian Brazil

unread,
Nov 23, 2016, 12:55:16 PM11/23/16
to Søren Krabbe, Prometheus Developers, soren...@gmail.com
On 23 November 2016 at 17:35, Søren Krabbe <s...@sokr.dk> wrote:
Thanks Brian.

I understand. However, I find it a little "backwards" to put the refresh responsibility on a server script of some sort. That script has no way of knowing when it's proactively time to refresh the token. On the other side, the prometheus scrape process itself will know just in time.

So if the expectation is that users place the refresh outside prometheus I would probably think a proxy on the prometheus server to handle the authentication would be better... though not elegant, I think :)

Do you think the project would accept pull requests for something like this?

Oauth implementations seem sufficiently non-standard that I don't think we'd be able to sanely maintain this within Prometheus itself.

Brian
 

Søren 

On Tuesday, November 22, 2016 at 11:09:02 PM UTC+1, Brian Brazil wrote:
On 22 November 2016 at 21:20, <soren...@gmail.com> wrote:
Hi,

I'm looking to scrape an endpoint that requires authentication using an oauth2 access token in the request header. When doing a static scrape, this is supported just fine with the bearer_token/bearer_token_file config options... but only until the access_token expires and needs to be refreshed using a refresh_token (which is the case for OAuth2?).

So...

1) Are there activities towards implementing support oauth refresh token flow?

The expectation is that you'll have some process updating the token in the bearer_token_file as needed.


2) Are there known workarounds for this? A suggestion in the chat was to try to use labels and label rewriting. Without having looked deeply into the suggestion I would think this means exposing the refresh_token (and client_secret) in the web UI config view, which I don't consider acceptable.

Relabelling explicitly doesn't cover auth, so that wouldn't help (and I'm not sure even if it were supported how this would help you).

Brian
 

3) Are there thoughts on a solution/effort required? I notice patterns looking similar in some of the service discovery options such as <azure_sd_config>. Perhaps this should be thought of as a service discovery option or does it make sense as an extension of the static scrape (it currently does in my mind)?

Thanks

Looking forward to your feedback

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscri...@googlegroups.com.



--

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

lu...@eichler.io

unread,
Aug 2, 2017, 4:42:47 PM8/2/17
to Prometheus Developers
I ran into the same challenges when I tried to secure the alertmanager with oauth.

My solution is to run https://github.com/gambol99/keycloak-proxy as a forward signing proxy next the prometheus server. Every requests to the apiserver will go through the proxy.

The proxy will manage the OAuth stuff and add an valid Bearer token to each request to the API server.

Reply all
Reply to author
Forward
0 new messages