-
-
Notifications
You must be signed in to change notification settings - Fork 138
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
feat(provider): add support for pre(external) auth'd session tokens #1441
feat(provider): add support for pre(external) auth'd session tokens #1441
Conversation
640ebc8
to
16f474d
Compare
Hi @vanillaSprinkles! 👋🏼 Would you mind to sign-off your commits? You can find instructions here |
yep will do - was hoping to get all the lint'ing fun done, remove the ancient comments, and re-run the binary first is the final lint-error due to the commented lines? edit: edit2: got one issue where env-var |
2be1719
to
60e53ca
Compare
59b931c
to
4105e17
Compare
Hey @vanillaSprinkles 👋🏼 I did a second pass over the code, and made a few changes, mostly to untangle credentials management. Everything works fine in my environment, but would you mind run a few tests in yours, to make sure all works as expected for you? And feel free to comment on my code as well :) |
hey @bpg ! it has a stacktrace on the auth-ticket and csrf (via env-var, untested via tf-file); though i didnt capture it. I am really diggin the class refactor (turns my hack into a thing of beauty!) .. but sadly, i keep getting distracted, so hoping friday i'll get to sit and tinker a bit more (and hopefully be able to commit something for testing the cred-paths) btw do you use a class object visualizer/mapper for golang? |
here's the stack trace details; i have not dug into the code yet - built from b3fcb2a (not updated the branch in a while) i've whipped up a shell loop to pass in several variations of credentials (pass + fail) via env-vars; going to have it write dynamically to a .tf file for static provider testing next, then will push this shell-monster up as well.
edit: i dont think you edited the flow of the PROXMOX_VE_OTP being sent in; if im not mistaken this should be the totp digits right? |
hey @vanillaSprinkles terraform-provider-proxmox/proxmoxtf/provider/provider.go Lines 129 to 135 in b3fcb2a
It looks like your provider's config does not have OTP is part of the terraform-provider-proxmox/proxmox/api/credentials.go Lines 48 to 61 in b3fcb2a
I guess that's not your use case? 😅 Could you post an example of the config you're testing with? |
no, not sure there is such thing for golang, as it doesn't really have objects / inheritance it the traditional OOP way. |
hey @bpg (test setup only has a single data-object just to get the provider kicked in) - config is simply 100% api (no ssh), blank provider config (nothing in there except i know some items require ssh'ing in but in my later-setup i plan to have a particular workspace for that (and hope proxmox-api's expand to not require ssh for some features, and instead to use api) env-vars:
with one of:
my cred-tester shell-loop only runs through env-vars at the moment vs dropping into the provider block; once i nail that part out i'll send it up. was able to see the stracktrace with Edit;
i'll re-test again tomorrow after some sleep - thanks again ! |
@bpg heya! overkill details: im used to full local rebases and as such i did not want to re-write history since your class refactor is your awesomness - i rebased locally and can force-push if you want (with the merge conflict using upstream fixes) test cred looper shell-fun:
regarding your code wizardry; the class re-work is great - nothing too much to criticise of (esp with me still ramping up to golang). and lastly, just ran a test using the repo's makefile example flags (what i hope to cleanup more and commit) and with an over-complicated check with manually tweaked .terraform/providers and .terraform.locl.hcl files and all seems well (off latest main pull+rebase) thanks again! |
Hey @vanillaSprinkles 👋🏼 |
adds provider config inputs: - env vars: PROXMOX_VE_AUTH_PAYLOAD; PROXMOX_VE_AUTH_TICKET with PROXMOX_VE_CSRF_PREVENTION_TOKEN - provider-config: auth_payload; auth_ticket with csrf_prevention_token Signed-off-by: vanillaSprinkles <vanillaSprinkles@users.noreply.github.com>
…add flags to terraform-plugin-docs Signed-off-by: vanillaSprinkles <vanillaSprinkles@users.noreply.github.com>
…ex.md Signed-off-by: vanillaSprinkles <vanillaSprinkles@users.noreply.github.com>
Signed-off-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
Signed-off-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
28ab486
to
e39d152
Compare
Signed-off-by: vanillaSprinkles <vanillaSprinkles@users.noreply.github.com>
d29129f
to
fbac792
Compare
@bpg heya! force pushed - not sure about these build steps stating tar is not available (im hoping its a github thing at the moment)
i'll place my api-auth-tester shell-script monster in a separate PR and can decide there if its wanted |
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.
Nice work @vanillaSprinkles!
LGTM! 🚀
@all-contributors please add @vanillaSprinkles for code, idea |
I've put up a pull request to add @vanillaSprinkles! 🎉 |
Hi |
hi @camaeel - i imagine it will work (with oidc, idp, ect); if it can be done via the webui then it should be curl'able and also TF'able - i dont have that stuff all wired up locally to get a full api-flow yet [ i plan to but it is low on my list at the moment ] the api-flow for proxmox user+pass+totp maybe very similar, might be worth seeing how it works with your setup - highlighted in the docs index.md at https://github.com/bpg/terraform-provider-proxmox/blob/main/docs/index.md#pre-authentication-or-passing-an-authentication-ticket-into-the-provider |
@vanillaSprinkles @bpg I implemented a little helper app that uses OIDC to obtain credentials and expose them as export commands to execute in the shell (or alternatively json output). Maybe it can be better integrated with this terraform provider. Currently I managed to achieve seamless integration with terragrunt. |
@camaeel thats pretty nice indeed - thanks ! it maybe a bit hard to integrate with the provider directly (esp with my skillset at the moment) - would be bpg doing his wizardry... (my own setup for testing out things has been slow going but cant wait to try out the idp components, so will use that at some point down the road) |
Every time the OS default browser will be open. I could expose a flag to output URL to be opened on the terminal, in cases where default local browser is not convenient. IMHO it might not work well if it is directly integrated with provider. But it can be called by the provider and the result can be consumed by the provider to populate credentials fields. I'm thinking about something like exec plugins in kubernetes provider: https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#exec-plugins (they are also supported by kubectl). EDIT: I just released v0.2.0 with support for outputting URL to STDOUT instead of opening default browser |
adds provider config inputs:
Contributor's Note
/docs
for any user-facing features or additions./fwprovider/tests
for any new or updated resources / data sources.make example
to verify that the change works as expected.make example
but i have ran this in my own env for testing the new provider config inputsProof of Work
Community Note
Closes #0000 | Relates #0000