[Feature] Support Secret for consul_acl_token

[sebastianreloaded]

It would be helpful to support the SecretID when creating tokens, so i am not forced to use the command line:
consul acl token create -policy-name "$POLICYNAME" -description "Agent Token" -secret=$TOKENSECRET

Affected Resource(s)

• consul_acl_token

References

• terraform-provider-consul/vendor/github.com/hashicorp/consul/api/acl.go

  Line 31 in e3c5fd4

  type ACLToken struct {

• terraform-provider-consul/vendor/github.com/hashicorp/consul/api/acl.go

  Line 606 in e3c5fd4

  // TokenCreate creates a new ACL token. If either the AccessorID or SecretID fields

[remilapeyre]

Hi @sebastianreloaded, we decided against returning the secret id in consul_acl_token as they would be written in the Terraform state and the update for the new ACL system in Consul 1.4 was so that places that needed to reference a token could do so with its accessor ID instead of its secret ID.

The Kubernetes, JWT and OIDC authentication methods can be used to set up authentication and have applications connect to the Consul cluster without having to pass the secret ID around. The Consul backend of Vault can also be used to securely have application obtain Consul tokens.

If you really want to get the secret ID in the Terraform code you can use [consul_acl_token_secret_id](https://registry.terraform.io/providers/hashicorp/consul/latest/docs/data-sources/acl_token_secret_id) but as the note in the documentation says it will save this secret ID to the remote state.

Does this solve your issue?

[sebastianreloaded]

Hi @remilapeyre, i was talking about setting the secretID when creating a token, not returning the created token.
I have pregenerated tokens and want to use exactly those. This is supported by the consul agent and the api, but not in this provider.

[andyrepton]

Just wanted to add that this is also something we'd like to do, we might make a PR with the functionality if that would be helpful!

[johnnyplaydrums]

This would be really helpful for us. The Consul API for token create supports setting a secret id in the API request, there's no reason the terraform provider shouldn't support the same attributes as the API. It's common for terraform to manage secret values (aws access keys), and it's left up to the user to ensure their state is secure. The option to specify a secret ID helps operators avoid the chicken/egg problem when spinning up a cluster. I get that there are other options mentioned for managing authentication, but not everyone will use those, which is why the API supports setting a secret id. Any chance this can be added to the roadmap @remilapeyre? 🙏

In the meantime, one workaround is to create these with local-exec, not a great solution but it can hold us over for now:

resource "null_resource" "consul_token_consul_agent" {
  provisioner "local-exec" {
    command     = "consul acl token create -description ${consul_acl_policy.consul_agent.description} -policy-name ${consul_acl_policy.consul_agent.name} -secret='${data.aws_ssm_parameter.consul_token_consul_agent.value}'"
    environment = local.consul_env_vars
  }
}

We pre-create the tokens and then store them in AWS SSM Parameter store. This makes bootstrapping the cluster much easier.

[johnnyplaydrums]

Hey @remilapeyre 👋 Given the uses cases described above, could this feature be added to your roadmap? It should be a relatively small task: Add a secret_id field to the existing consul_acl_token resource. This new secret_id field would be passed to the existing API call as SecretID.

[seanamos]

The original reason for not storing secret_id in the state, or allowing it to be specified, is that is that it would leak into your Terraform state.

However, its the accepted norm now that your Terraform state needs to be securely stored and access controlled because something sensitive will find it's way into the state.

This eliminates the reason for not adding this. I think it needs to be revisited. It greatly simplifies automated provisioning if you can pre-generate the tokens (secret_id).

[sebastianreloaded]

After using the null_resource for a long time, i now compile my own version of the provider and use "dev_overrides" in .terraformrc. Has anyone better ideas?