two factor otp auth for provider

[vanillaSprinkles]

i've gone over some of the PRs re auth and documentation stuff, but I could not quite find out exactly why the otp option (or PROXMOX_VE_OTP env-var) is marked for deprecation ( at https://registry.terraform.io/providers/bpg/proxmox/latest/docs#otp )

I was trying to get it working in proxmox 8.2.2 with provider 0.60.1 but getting a bit of auth-errors (when disabling the users totp then auth works with user/pass - so guessing the ticket'ing bit changed with proxmox 8).

Curious if the (when it worked) otp mode in the provider created its own new session ticket every time running a plan/apply, or if it reused one...

And finally hoping to see some level of support for it (though since im using direnv i may just stick to user/pass over ssh-agent), even if its a helper-agent that passes along the ticket and the CSRFPreventionToken strings

EDIT: resolved with merge of #1441

[bpg]

Hi @vanillaSprinkles 👋🏼

I'm curious about your use case for OTP with the provider. Would a separate API Token used exclusively for the provider auth work for you instead?

OTP is primarily designed for interactive logins, where the user must enter their password as the first factor, and an OTP as a second factor provided from an independent/external source. For system-to-system auth, like between the provider and PVE, the API Token is the preferred method, as it can be better protected than the user's password, have a shorter lifetime, be easily tailored to a subset of permissions, revoked, etc.

And finally hoping to see some level of support for it (though since I'm using direnv I may just stick to user/pass over ssh-agent), even if it's a helper-agent that passes along the ticket and the CSRFPreventionToken strings

Not quite sure I've got this. PVE REST API auth and SSH auth are technically independent of each other. For any production systems, you should not use the root user account, which is configured by default and allows you to authenticate both with the PVE API and SSH. Instead, I highly recommend setting up a separate API Token for API access, and a non-privileged sudo user for SSH, and configuring public key auth via ssh-agent. I believe you can dynamically load ssh key(s) to the ssh-agent using direnv config, but I don't have much experience with it.

[vanillaSprinkles]

for use case with otp:
I dont necessairly like the idea of having a long life API Token hanging around (even with an expiration, i'd still need to generate a new one and then get that to my client - im not using hashicorp vault to handle that but adds that much more complexity) - and yes it could be passed from an encrypted app (on my client) into the env for TF to use and send along...

Like for AWS auth'ing, the user can pass in user/pass + totp, which grants an hour (or custom) time limit for the session based auth (access-key, secret-access-key, session-token) - and I do think that would be a nice flow for proxmox (although proxmox's is simply access/ticket and passes the ticket (pveauthcookie) around - and from my few tests the csrf prevention token is not required). so the flow for aws is like user has their non-changing creds + totp and that yields a time-limited session-credential set; which due to totp makes it a bit more ideal than a long term non-rotating credential.

for that last "and finally" that i wrote: im hoping to not use ssh to send commands to manage proxmox - i basically use direnv to manage my secrets as I can have it trigger things based on a folder I am working within. My goal is to have root only used for bootstrapping the system, create a pve-realm'd user with more "full" access, with totp, and eventually have scoped privs for lower ranking users (and then locking down root to 127.0.0.1 access with totp only; and ssh to the system would also never be root; a different stage of 'bootstrapping' for the OS) - but certainly im not trying to have a workflow where a user logs into webui, creates a short-lived (several hours) api-token then add that to secrets for TF to use - thats what I believe totp handles (the random auth component)

more edits:
Im wonering if an option would be to have env-vars for the PVEAuthCookie (aka token) and CSRFPreventionToken be inputs to the proxmox provider, thus generating those would be outside of TF, simplifing the provider's logic for otp-input, and still allowing a totp workflow

[vanillaSprinkles]

i actually got to play around in the provider go files a little bit today.. (found it more of a pain to test the local build with tofu than anything else - but that is another problem for another day)

managed to make the provider accept the ticket and csrf as input fields; wondering though after going through data-structs if we just want to pass it in the raw-json blob which also includes more fields (like username, and cap) => aka i did not follow the use-cases to see if the capabilites and username part of the ticket-response were actually used anywhere

still need to run through a bit of cleanup before i send a PR for review and critiquing - be another day or so ish

[vanillaSprinkles]

@bpg i finally made a fork and PR of my stuff (to my fork) before i finish a few things (namly only an edge-case stack-trace i found with invalid inputs - and some more docs like using curl to auth with TOTP): https://github.com/vanillaSprinkles/fork__bpg__terraform-provider-proxmox/pull/1/files

curious on a few things:

• shall i make a PR to your repo for commenting within?
• naming of the config-args/env-vars:
  • auth_payload for the full ticket response json-blob
  • auth_cookie, for only the ticket-itself, maybe it should be auth_token or auth_ticket? this couples with csrf_prevention_token and it is a monster
• logic location for precidence:
  • currently for the non-ssh auths, the priority is: auth_payload > auth_cookie and csrf_prevention_token > api_token > username and password - (and a stack-trace exists if the auth_cookie is not a valid format, like value abc)
  • this logic happens in NewCredentials (in file proxmox/api/credentials.go) - maybe the if-block should instead live in NewClient (in file proxmox/api/client.go), along with some new functions?

[bpg]

@vanillaSprinkles Thanks for working on this feature! I think a PR to the upstream would be better. :)

Regarding the other points, I'll need to spend some time on the code and will give you my feedback in a few days.

[vanillaSprinkles]

sounds good, i'll try to fixup that stack trace then PR into upstream soon

edit: woo here we go: #1441

i have not done much golang so critique away (and add all the reasons) - i added a few verify and todo sections that i think should be cleaned up before merged (related to stuff im not 100% sure of)

cheers!

[vanillaSprinkles]

been fun so far; ended up going with auth_ticket instead of auth_cookie

• re-ran through testing valid and invalid creds ensuring no stack traces; ( did not automate this, lots of combinations - i wouldnt know how to cleanly add something like that other than a bash-ism tied to the makefile )
• lint-errors now on the inline-comments with some todos regarding placement of if-logic and username checks