[Bug]: With mutualTLS setup getting error client_auth is being deprecated for auth_login_cert.

[arpanrec]

Terraform Core Version

1.6.6

Terraform Vault Provider Version

3.24.0

Vault Server Version

1.15.2

Affected Resource(s)

provider "vault"

Expected Behavior

client_auth is being deprecated for auth_login_cert. My current vault config doesn’t have any PKI Auth setup, I needed this client_auth because I have mutual TLS enabled. and the authentication process is userpass.

I am expecting I should be able to use vault userpass login with mutual TLS enabled

Actual Behavior

As auth_login and auth_login_cert both are login methods terraform is throwing an error saying it's a conflict.

Relevant Error/Panic Output Snippet

❯ terraform plan

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Conflicting configuration arguments
│ 
│   with provider["registry.terraform.io/hashicorp/vault"],
│   on provider.tf line 10, in provider "vault":
│   10: provider "vault" {
│ 
│ "auth_login": conflicts with auth_login_cert
╵
╷
│ Error: Conflicting configuration arguments
│ 
│   with provider["registry.terraform.io/hashicorp/vault"],
│   on provider.tf line 10, in provider "vault":
│   10: provider "vault" {
│ 
│ "auth_login_cert": conflicts with auth_login

Terraform Configuration Files

Here is my vault provider config. I did a micro testing just the provider and a basic kv resource, you will always get the same error

provider "vault" {
  address         = local.codified_vault_addr
  ca_cert_file    = var.codifiedvault_vault_ca_file
  skip_tls_verify = false
  token_name      = "codified_vault"
  auth_login_cert { # Changed from client_auth
    cert_file = var.codifiedvault_vault_client_cert_file
    key_file  = var.codifiedvault_vault_client_key_file
  }
  auth_login {
    path = "auth/${var.codifiedvault_login_username}/login/${var.codifiedvault_login_username}"
    parameters = {
      password = var.codifiedvault_login_password
    }
  }
}

Steps to Reproduce

Just add vault provider with auth_login and auth_login_cert.

Debug Output

No response

Panic Output

No response

Important Factoids

Now if you change auth_login_cert to client_auth your code will work with the below Warning.

Plan: 26 to add, 0 to change, 0 to destroy.
╷
│ Warning: Argument is deprecated
│ 
│   with provider["registry.terraform.io/hashicorp/vault"],
│   on provider.tf line 10, in provider "vault":
│   10: provider "vault" {
│ 
│ Use auth_login_cert instead
╵

As i already explained before my vault doesn't have a PKI Auth module, but I was using client_auth for mutual TLS auth, Here is my vault server tcp listener template

listener "tcp" {
  address                             = "0.0.0.0:{{ pv_vault_node_port }}"
  tls_disable                         = false
  tls_cert_file                       = "{{ pv_vault_tls_dir }}/vault.fullchain.pem"
  tls_key_file                        = "{{ pv_vault_tls_dir }}/vault.key"
  tls_require_and_verify_client_cert  = true
  tls_client_ca_file                  = "{{ pv_vault_tls_dir }}/ca-client-mtls-crt.pem"
}

References

No response

Would you like to implement a fix?

None

[fairclothjm]

Thanks @arpanrec for reporting! If I am understanding correctly there are 2 options

1. Make auth_login and auth_login_cert not mutually exclusive
2. Do not remove client_auth from any future versions of TFVP

Does that sound right to you? If yes, I am curious if you have reason to prefer one over the other? Thanks!

[arpanrec]

@fairclothjm Thanks for the response,

1) I don't have enough knowledge to comment on point 1. As vault should support only one way of authentication for a single provider configuration block, so in my mind (token, auth_login, auth_login_cert) all these are mutually exclusive is totally make sense and no need to change (Person Opinion). But there might be other use cases where I don't have any experience.

2) client_auth (or pick any parameter) to provide the option for vault TCP listener mutual TLS auth (which is not vault TLS certificates auth method). So "Do not remove client_auth from any future versions of TFVP" makes sense here.

[fairclothjm]

Thanks! Option 1 was hypothetical. I have not investigated if there are cases where it could make sense. I will discuss this issue with my team. Thanks!