-
Notifications
You must be signed in to change notification settings - Fork 181
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
Separate auth for REQ_URL and *.url #290
Comments
I'm hitting a similar issue after testing an upgrade of Kube-Prometheus-Stack, I now can't pull from my public repositories using BitBucket as its trying to supply auth creds during the pull. |
Looking at the Grafana Helm chart it appears this commit breaks the ability to use |
This issue has been automatically marked as stale because it has not had any activity in the last 60 days. Thank you for your contributions. |
I used kustomize to locally download the file as a workaround: apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: tempo-operational-grafana-dashboard
files:
- tempo-operational-dashboard.json=https://raw.githubusercontent.com/grafana/tempo/v2.5.0/operations/tempo-mixin-compiled/dashboards/tempo-operational.json
options:
disableNameSuffixHash: true
labels:
grafana_dashboard: "1" |
Issue abstract
Right now
REQ_USERNAME
andREQ_PASSWORD
is used for authenticating for both the REQ_URL and any configmaps/secrets with*.url
key, I believe it would be good for these to be handled separately.Our setup
We are using this from the grafana helm chart, with auth turned on on grafana we need to supply auth in order to hit the reload API on grafana for the different resources, and so we set
REQ_USERNAME
,REQ_PASSWORD
.We do however also download dashboards from grafana.com, e.g.
https://grafana.com/api/dashboards/13329/revisions/latest/download
, using the*.url
notation. As of right now this will use the same configured authREQ_USERNAME
andREQ_PASSWORD
as is used to hit the grafana reload api, since these are local accounts on our own self-hosted instances, this will not work.Example solution
I think omitting auth by default for
*.url
and since secrets are an option to use, and basic auth is used, setting them in the value of the*.url
, e.g.username:[email protected]/api/dashboards/13329/revisions/latest/download
, would solve this issue.Example request log:
The text was updated successfully, but these errors were encountered: