-
Notifications
You must be signed in to change notification settings - Fork 3
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
Use OAuth token instead of http basic auth for prometheus access #62
Conversation
This change is required in order to match changes in STO[1] where we will stop allowing http basic auth for access from grafana to prometheus, and use an oauth token from a new restricted service account instead. [1] infrawatch/service-telemetry-operator#549
I tested this locally against an environment deployed from my STO PR branch like so: (Edit: This is fixed below) Before we merge this, I'm noticing that we may have a problem. While this change is required in order to test the new code that will soon be on the STO master branch, there are no "stable-1.5"-like release branches in this repo, so if this merges, you will no longer be able to use it to test the release version of STF. Creating the branch is trivial, but I have not yet looked at what will be required to adjust the jenkins jobs to use the correct branch at the correct time, and feel like this is way outside my scope at the moment. Looking for help from QE to figure out how to handle this. CC: @ayefimov-1 @myadla |
I would suggest adding a var to determine whether to use user/pass or get a token. Also, a branch would be a good idea, but we still have a temporary issue trying to figure out how to point jenkins at the right branch. |
ansible.builtin.shell: | ||
cmd: | | ||
oc get secret default-prometheus-htpasswd -ojson | jq '.data.auth, .data.password' | sed 's/"//g' | ||
register: prom_secret | ||
oc create token stf-prometheus-reader |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For backwards-compatibility, I suggest keeping the "get password" and "get user" tasks, and stick them in a block, guarded with a when: X
.
The new token generation can be in a complementary block (i.e. when: not X
)
To keep the curl tasks clean, I suggest adding a "prom_auth_string" that would be either -u "{{ prom_user }}:{{ prom_pass }}"
or -H "Authorization: Bearer {{prom_token}}"
Thanks, @elfiesmelfie , I'll add a variable that selects between the methods as a temporary measure until the branch awareness can be sorted out. |
changed_when: false | ||
- when: prom_auth_method == 'password' | ||
block: | ||
- name: "Get the default-prometheus-htpasswd secret" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This diff is unfair; every one of these blocks was in the existing code! ;) The changes are mostly indenting.
I haven't looked into why, but the task names are never printed during execution so it's hard to follow; nevertheless, here is my evidence of testing: Token authSTF from csibbitt/STF-1549_prometheus_token_auth branch
Password authSTF from stable-1.5 branch Fails with token auth:
Works with password auth:
I've also gone ahead and created the stable-1.5 branch in this repo based on the current master commit so that we are ready if the jobs can be made branch-aware. This workaround should never really need to merge there, as we should be in token-only mode as of STF 1.5.4; but even if we do merge it to that branch everything will still work. |
bdad069
to
24b8ecc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me.
This change is required in order to match changes in STO where we will stop allowing http basic auth for access from grafana to prometheus, and use an oauth token from a new restricted service account instead.
Depends-On: infrawatch/service-telemetry-operator#549