Add command to validate config

[kasimon]

Feature Request:

Environment:

• Vault Version: v0.8.2 ('9afe7330e06e486ee326621624f2077d88bc9511')
• Operating System/Architecture: Debian 8

Please add a vault command to validate its config file, like consul has consul validate. This would be very helpful for example when deploying vault with puppet, because puppet can verify a new config file before deploying it with validate_cmd.

[LinAnt]

I also use the consul validate command to validate the configuration before starting the consul service. This is really nice to have when using systemd.

[tristanmorgan]

Even if it was a simple syntax check I would like to use it with test-kitchen to ensure the config template was rendered correctly.

[tristanmorgan]

Hi @meirish , is this feature request a possibility?

[aphorise]

To ask more broadly - is the request for a generic HCL syntax validation check? - I'm just curious what are the exact details and criteria in terms of a well-qualified schema? - eg would it be checking that each matching stanza is in the required type?

I agree that some minimal HCL syntax checking would be nice in case of any unforeseen / empty variables. I'm wondering if consul validate does something similar?

[roberth]

Beyond syntax validation it'd be nice to validate the storage backend configuration. That's probably quite a bit more effort, but just loading the config is a good start, to just check the syntax.

[vishalnayak]

Issues that are not reproducible and/or not had any interaction for a long time are stale issues. Sometimes even the valid issues remain stale lacking traction either by the maintainers or the community. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days. Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant but is wrongly closed, we encourage reopening them.

Please refer to our contributing guidelines for details on issue lifecycle.

[aphorise]

@narayan-iyengar - do you have any inputs or ideas if this is already been worked on or scheduled for release in a foreseeable version? - it would be nice to get a status update before the 5th anniversary of the request.

The request is still relevant since any bad HCL that may prevented with a check (even most minimally) is better than a bad file / ConfigMap resulting in the failure of a node or cluster. What's more most apps like consul validate, haproxy -c -f /file.cfg or others mostly offer some minimal sanitation check if not extended validation or warning related to bad values such as bad IP address or 0.0.0.0 binding with 10.1.1.1 (which overlap).

[aphorise]

Re-quoting note from #8338:

On the most recent versions of Vault (eg: 1.12.0) the default log levels actually give a WARN message regarding portions of the log that it doesn't understand. So I took your original conf (from the start) - and trying to start the Vault process then shows:

sudo /usr/local/bin/vault server -config=/etc/vault.d/vault2.hcl
  # A storage backend must be specified
  # … [WARN]  unknown or unsupported field vault found in configuration at /etc/vault.d/vault2.hcl:3:1
  # … [WARN]  unknown or unsupported field garbage_block found in configuration at /etc/vault.d/vault2.hcl:12:1
  # … [WARN]  unknown or unsupported field cache found in configuration at /etc/vault.d/vault2.hcl:17:1
  # … [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""

So even at present this can be used as a form of soft sanitation checks against the conf to ensure no WARN occur before restarting services.

[ncode]

This one would be specially useful to validate vault agent templates and broken syntax for template files. Same way it's possible consul-template.