Allow basic authentication credentials to reside inline with target URL

[asaf400]

What did you do?

I attempted to use relabel_config to modify a kubenetes service discovery targets ('kubernetes-service-endpoints'),
so that a basic auth protected target could be read, while the credentials are dynamic and are part of the source labels..

For my point of view (after reading all the docs I could find),
there are only two options:

Given the following source labels (before labels):
[address, __meta_some_port, meta_username, meta_password]
where values are [192.168.1.104:80;1936;admin;PasSw0rd;]
this regex '(.+)(?::\d+);(\d+);(\w+);(\w+)'
this replacement: '$3:$4@$1:$2'
would produce a valid http url:
http://admin:PasSw0rd@192.168.1.104:1936/metrics
with address as:
admin:PasSw0rd@192.168.1.104:1936
and scheme as the default 'http', as well as metrics_path as the default '/metrics'

the complete address works perfect in curl, but not in prometheus..

What did you expect to see?

For method 1, I expected prometheus to scrape the targets with the provided inline basic auth credentials..

What did you see instead? Under which circumstances?

Target Error Column shows:
' parse http://admin:PasSw0rd**%40**192.168.1.104:1936/metrics: invalid URL escape "%40"'

%40 is the @ in Hex on the Ascii table..

Seems prometheus is unable (not ready \ not implemented) to parse basic authentication credentials inline with the "address", and with that conclusion I want to suggest a feature:

Either enable method 1 to work, by correctly parsing both regular addresses and basic auth inline addresses..

or enable method 2 which is:
respect a new 'meta label', where there are currently 'address ', 'scheme', 'metricspath'
I suggest adding 'username' and 'password', which would be used as credentials

Environment
prometheus 2.2.1 on RHEL7 - pod ontop openshift 3.6 (k8s 1.6)

• Prometheus version:

prometheus 2.2.1 HEAD rev=bc6058c8127a..........

[brian-brazil]

This is explicitly not supported, you need to put it in the scrape_config.

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

[asaf400]

@brian-brazil Thanks, I though so too that this is more of a question then an issue, however i posted here anyways in light of the fact that this a limitation of prometheus (by design or not), and should be considered as a feature request..

However I just found out that my mentioned 2nd method is actually implemented?
https://github.com/mrsiano/openshift-grafana/blob/master/prometheus-high-performance.yaml#L292

Will attempt that...

[brian-brazil]

That's not a feature of Prometheus, and would be considered a security bug if it were.

[nickle-ye]

hi, I have encountered the save issue.

Is there any chance that I can dynamic set up the auth info from the label info of target instead of hard code on the scrape_config?

As different target would need individual basic account, the common one won't be worked.

[asaf400]

I simply reverted to hard coding the auth setting and cloning the scrape config for each different target..

…

On Mon, 9 Jul 2018, 15:09 Nick Ye, ***@***.***> wrote: hi, I have encountered the save issue. Is there any chance that I can dynamic set up the auth info from the label info of target instead of hard code on the scrape_config? As different target would need individual basic account, the common one won't be worked. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4026 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANgzrkyrRk5KUcXcWVUEf88L3DgH0aQ3ks5uE0gOgaJpZM4S_2eJ> .

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.