Add support for alternative auth methods using a method-agnostic implementation

[jtcressy]

Hi, I decided to take a crack at #438 and I'm attempting to implement a method-agnostic authentication mechanism.

Additionally, this should still close #351, #428, and #346.

Use of this new config block overrides any token fetched from the token helpers or environment, including if you provide a token via the token provider argument.

So far, I've only tested this with approle and userpass. In theory, all auth methods should work as long as they don't require anything complex. An acceptance test was only written for approle, so if we need to add coverage for other login methods anyone may feel free to do so.

My implementation introduces a new config block called auth_login:

provider vault {
  address = "http://localhost:8200"
  auth_login {
    path = "auth/approle/login"
    namespace = "my-team/sub-namespace" # only needed if auth method is mounted within another namespace (enterprise only)
    parameters = {
      role_id = var.role_id
      secret_id = var.secret_id
    }
  }
}

Some auth methods use parameters as part of the url, and those can just be included in the path argument:

provider vault {
  address = "http://localhost:8200"
  auth_login {
    path = "auth/userpass/login/${var.login_username}"
    parameters = {
      password = var.login_password
    }
  }
}

Acceptance tests have been ran against a local Vault Enterprise 1.1.5 premium server with TF_ACC_ENTERPRISE=1 following the regex TestAcc.*ProviderConfigure:

=== RUN   TestAccAuthLoginProviderConfigure
2019/09/27 15:10:50 [INFO] Using Vault token with the following policies: root
--- PASS: TestAccAuthLoginProviderConfigure (0.73s)
=== RUN   TestAccNamespaceProviderConfigure
--- PASS: TestAccNamespaceProviderConfigure (0.93s)
PASS
ok  	github.com/terraform-providers/terraform-provider-vault/vault	14.142s

Documentation included.
Again, I think I could've done more test coverage but this should at least validate this PR.

[tyrannosaurus-becks]

@jtcressy I'm super excited about this PR. Thanks for submitting it. Looking forward to hearing your thoughts.

[tyrannosaurus-becks]

Well done. I ran the tests and everything is in order. The new code paths are hit. The docs are excellent. Just want to say a huge thank you for adding this.

💯

[StephenWithPH]

@jtcressy ... this is great work! Thank you for contributing.

Do you know how this will interact with token (typically set with the VAULT_TOKEN environment variable)?

The use case is for human users to set VAULT_TOKEN, while build automation provides valid values for role_id and secret_id.

variable role_id {
  type = string
  default = ""
}

variable secret_id {
  type = string
  default = ""
}

provider vault {
  address = <some vault>
  auth_login {
    path = "auth/approle/login"
    parameters = {
      role_id = var.role_id
      secret_id = var.secret_id
    }
  }
}

( cc @tyrannosaurus-becks )

[jtcressy]

Currently, the order of precedence is such:

• if auth_login defined and results in successful login, this token is used.
  (if login fails, the provider will panic instead of falling back to another method)
• else, If token is defined in the provider config, this is used.
• else, If VAULT_TOKEN defined in the environment, this is used.
• else, provider panics with "no vault token found"

note, auth_login even overrides the token parameter if both are defined in the provider config.

Suggestions:

• You could still use approle for human-driven tf plans
• Or, extrapolate the auth method entirely and use variables for path and parameters. Then, you can still use approle in CI and then something like userpass or ldap on the workstation.

[StephenWithPH]

Or, extrapolate the auth method entirely and use variables for path and parameters. Then, you can still use approle in CI and then something like userpass or ldap on the workstation.

That was my plan B. It has the (small) downside of breaking our existing solution around token. I'll noodle on some other approaches.

Regardless, thank you for your work!