Using session key when applying from plan produces unauthenticated error about terraform-provider-bitwarden HOT 7 CLOSED

Hi @Poulpatine !
Thanks for gathering this information.

vault_path content has been manually copied from a login with bw cli.

Could you elaborate on this ? Do you mean you copied the local Vault from the default path to another location, and you specified this other location as vault_path in the provider's configuration ?

I understand than you generate a plan as a first step, and then execute the plan as a second step, is that correct ?

If a new terraform plan is launched, then the apply is ok.

What do you mean by that ?

In general, I'm very interested in your your case here. Why did you decide to provide a session key instead of giving the provider credentials, so you don't have to login manually: trust ?

If a new terraform plan is launched, then the apply is ok.

If you provide a session key, I think you need to either:

1. change the vault_path to the actual path of your local Vault (depends on the OS)
2. or run
   a.export BITWARDENCLI_APPDATA_DIR=./.bitwarden/
   b. cd <your-terraform-workspace>/
   c.bw config server <your-server-url>
   d.bw login

from terraform-provider-bitwarden.

vault_path content has been manually copied from a login with bw cli.

I mean that the data.json content has been copied a single time manually from $BITWARDENCLI_APPDATA_DIR/data.json in a variable. And the content of this variable is used at each Terraform run with :

# BW_VAULT is the content of data.json located in 
# TF_VAR_bw_vault is used as vault_path
   - export TF_VAR_bw_vault=$(mktemp -d)
   - cat "${BW_VAULT}" > ${TF_VAR_bw_vault}/data.json

If a new terraform plan is launched, then the apply is ok.

When I use the plan.cache generated from the first job. my terraform apply fails. But if I generate a new one with terraform plan -intput=false -out="plan.cache" it goes well.

The reason I use a session key is that I just want to avoid to receive a "new device" email at each CI run.

from terraform-provider-bitwarden.

Thanks! It's a bit more clear.
You mean that the apply doesn't work if you run apply in a separate job, but if you run plan and apply in a row you don't face the error is that right ?

I'm surprised you get a notification every time the provider runs. I also have a Vaultwarden Vault for one of my projects, and I don't get notifications that often. Have you tried using a Client ID and Client Secret ?

from terraform-provider-bitwarden.

You mean that the apply doesn't work if you run apply in a separate job, but if you run plan and apply in a row you don't face the error is that right ?

Yes, exactly.

I'm surprised you get a notification every time the provider runs. I also have a Vaultwarden Vault for one of my projects, and I don't get notifications that often. Have you tried using a Client ID and Client Secret ?

Yes, I'm providing client ID / Secret in addition to Master password but I get an email every time.

from terraform-provider-bitwarden.

Yes, I'm providing client ID / Secret in addition to Master password but I get an email every time.

Which version of Vault Warden do you have ? I'm still running on 2022.12.0. I just checked: login in from the UI results in an email, but not using Terraform. I do have MFA enabled with the account (if it makes any difference).

Two ideas to move forward:

• have you tried comparing the content of both plans, to find out if there are any obvious difference @Poulpatine ? If I unlock my Vault, make a copy (cp or cat >), I can still access the copy with the session key generated when pointing at the original Vault.
• can you replace mktemp -d with a hard-coded directory ? If the value of TF_VAR_bw_vault is not passed properly from the first job to the second job, the second job would create a Vault because it doesn't exist and throw an authentication failure because the session key is invalid.

from terraform-provider-bitwarden.

I'm using Vaultwarden Version 2023.5.0.
I've made a test this morning with MFA but I've also received a mail.

On your suggestion I've compared both plans and the only different thing was the TF_VAR_bw_vault.
Hence, I've modified my CI to use a fixed location for the vault_path and now the problem is fixed.

Sorry for the noise and many thanks for your help.
We can close the issue.

from terraform-provider-bitwarden.

Alright, good to know!

from terraform-provider-bitwarden.