Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Support Secret for consul_acl_token #289

Open
sebastianreloaded opened this issue Sep 30, 2021 · 5 comments
Open

[Feature] Support Secret for consul_acl_token #289

sebastianreloaded opened this issue Sep 30, 2021 · 5 comments

Comments

@sebastianreloaded
Copy link

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

@remilapeyre
Copy link
Collaborator

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
Copy link
Author

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
Copy link

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
Copy link

johnnyplaydrums commented Jul 19, 2022

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants