"consul agent" should support -token-file

[whiskeysierra]

Please search the existing issues for relevant feature requests, and use the reaction feature (https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to add upvotes to pre-existing requests.

Feature Description

The consul login command has the ability to write tokens to files, namely the -token-sink-file option. It would be nice if the consul agent command would get a -token-file option (incl. the CONSUL_HTTP_TOKEN_FILE env var) to make those two commands integrate nicely.

Use Case(s)

Generating a token and then using it requires to manually or using 3rd party tools (e.g. jq) to produce valid client config files or hcl fragments.

[bisakhmondal]

Hi @jsosulska, can I give it a try? Also, it would be great if you mention some useful docs. Thanks.

[samajain]

Hi @jsosulska, I have used consul extensively in production environments before and I am learning go as part of my new work project. Can I work on this?

[Ca7Ac1]

Hello! I wanted to ask about the status of this issue. If no one is working on it I'd love to try to make a contribution!

[jkirschner-hashicorp]

Hi all,

I was just reminded of this issue because of @Ca7Ac1 's latest comment. Thank you for the multiple offers to contribute to this issue!

Let me think about this for a bit (by mid-July) before I respond more fully. I think the next step is to agree on a design, not to begin implementation. If potential collaboration on a design is a form of contribution you're interested in, let me know!

Things to think through include:

• The agent config file has multiple multiple slots for ACL tokens (initial_management, default, agent, agent_recovery, config_file_service_registration, replication, etc). The design would presumably need to allow for setting selected slots with distinct tokens.
• This issue mentions support for pulling agent config secrets from files. But what about other sources? such as...
  • Environment variables (mentioned in #10249)
  • Secrets manager (such as Vault; mentioned in https://github.com/hashicorp/consul/issues/8306; also related to https://github.com/hashicorp/consul/issues/15883)
• What about other secrets besides ACL tokens?
  • Gossip encryption key
  • Certs (that you pull from a cert issuer or secrets manager on startup rather than store on disk)

I'm not suggesting we need to implement all of these things at once, but the approach/design should be consistent, which requires considering the holistic requirements/design upfront.