Open googol opened 1 month ago
If there's no major difference implementation-wise, I'd prefer having the properties straight on the provider, for easier dynamic configuration. If the terraform code needs to be callable by persons, as well as something like gitlab ci, the JWT needs to be dynamically configurable, which for the vault provider requires a dynamic
block, which is clunky old syntax:
provider "vault" {
dynamic "auth_login_jwt" {
for_each = var.jwt != null ? { "jwt" = var.jwt } : {}
iterator = each
content {
role = "role-name"
mount = "gitlab"
jwt = each.value
}
}
}
but if it was directly on the provider this would collapse to something like:
provider "vault" {
jwt_auth_role = var.jwt != null ? "role-name" : null
jwt_auth_mount = var.jwt != null ? "gitlab" : null
jwt_token = var.jwt
}
Since Nomad now has support for logging in with JWTs issued by external identity providers, and those can be configured by this terraform provider, the next step would be to enable login with these tokens.
The endpoint to use is documented here: https://github.com/hashicorp/terraform-provider-nomad/pull/448
The configuration syntax could be either individual properties like, where they both have to be null or not-null:
or a like the
auth_login_jwt
block in the vault provider, where both would be required if the block is defined: