Add jobs.api_key so jobs can use api_key instead of username/password#256
Add jobs.api_key so jobs can use api_key instead of username/password#256cognifloyd wants to merge 4 commits intoStackStorm:masterfrom
Conversation
arm4b
left a comment
There was a problem hiding this comment.
Thanks for the PR, but I'm afraid the edge case as I remember caused by inability to create the required LDAP user and seen in a single environment shouldn't be a reason to apply it as a workaround to everyone in the community. I don't believe this PR should be part of the official Helm chart.
I'd recommend using kustomize for very specific cases, it's a de-facto standard perfectly suitable for this example that can help.
See https://austindewey.com/2020/07/27/patch-any-helm-chart-template-using-a-kustomize-post-renderer/
values.yaml
Outdated
| # For jobs that need to use the ST2 APIs, if you set jobs.api_key | ||
| # then the jobs will use jobs.api_key instead of st2.username/st2.password | ||
| # This is only useful when running `helm upgrade` as the api_key must be present | ||
| # before the apikey-load job runs (it will use this api_key if defined). |
There was a problem hiding this comment.
Relying on API key which will only be available on upgrade, - the scenario here looks like a problem in something else.
|
OK. I would insist on using an API key even without the issues with LDAP. That said, I think there are a couple of changes that might facilitate using a helm post-processor instead. I'll mark this as draft for now, and probably close it later. |
|
I am not sure if this fits, but I also have certain use cases (install packs and running other jobs using puppet) where using API-keys or auth tokens to authenticate is better than using username/password (since in my case the puppet install is not aware of the LDAP credentials of the service account, it is just injected in the config at a later stage). I have been playing around with the puppet module to add the ability to install packs with API-key instead of doing user auth (currently it requires authenticating as a Stanley system user to get the tokens, my environment has no Stanley user). So I won't say it's a single environment use case and might be something that is helpful for the community in general. Also again, it is okayish/safer to put an auth-token/API-key in the repo/conf/hiera than LDAP credentials of a user, at least in our case. For the chicken and egg problem - maybe we can make the scripts use username/password is api-key is missing, and use them to generate a "system" api-key that can be used for further transactions. |
|
@armab I think I clarified the issues with |
|
Closing in favor of #262 |
I always insist that automated jobs use API keys instead of username/password. This allows using an st2 API key with the helm hook jobs during
helm upgrade. Just setjobs.api_keyto a key that you created for helm to use.Closes #233