fix: dont-query-secrets #82
Conversation
|
IF you want to go this strategy of mounting the token to the pod via the SA, you need to add it to the SA spec as a secret, in the operator code, there is an example of this here in the k8s docs. I say if though because im not sure how you are going to mount this easily. As portrayed in the main state of the code, the secret is made from a oc get secret -n openshift-user-workload-monitoring | grep prometheus-user-workload-token | head -n 1 | awk '{print $1}'
prometheus-user-workload-token-cw7jlThis is why I make consecutive calls to it rather than mounting it. Also this token is created by the system so not sure you can mount it in a consistent way in yaml without having to get this identifier. I suppose you might be able to do something from the static |
|
@Gregory-Pereira I don't believe we need to mount the bearer-token as a secret for the SA, we don't need to use the token outside of this pod, all communication is done inside the pod. So it can just be passed to the function using it. @osmman WDYT? |
you are correct. The service accounts token is automatically mounted to pod by serviceaccount admission controller and I expect that it is same token which is used by python kubernetes client used in SBJ. |
There was a problem hiding this comment.
Yeah all this checks out. Sorry for my misunderstandings, after meeting with Jason to understand the changes and re-review ing this gets my conceptual approval. I have not tested it but If you can vouch that it works as intended, I am happy with the direction of the pr.
/lgtm
|
/retest |
Changes the script to, use the bearer token of the service account used to run the SBJ pod.
CC: @tommyd450 @osmman @lance @Gregory-Pereira