* upgrade hcl dependency on api pkg
This upgrades the hcl dependency for the API pkg,
and adapts its usage so users of our API pkg are
not affected. There's no good way of communicating
a warning via a library call so we don't.
The tokenHelper which is used by all Vault CLI
commands in order to create the Vault client, as
well as directly used by the login and server
commands, is implemented on the api pkg, so this
upgrade also affects all of those commands. Seems
like this was only moved to the api pkg because
the Terraform provider uses it, and I thought
creating a full copy of all those files back under
command would be too much spaghetti.
Also leaving some TODOs to make next deprecation
steps easier.
* upgrade hcl dependency in vault and sdk pkgs
* upgrade hcl dependency in vault and sdk pkgs
* add CLI warnings to commands that take a config
- vault agent (unit test on CMD warning)
- vault proxy (unit test on CMD warning)
- vault server (no test for the warning)
- vault operator diagnose (no tests at all, uses the
same function as vault server
* ignore duplicates on ParseKMSes function
* Extend policy parsing functions and warn on policy store
* Add warning on policy fmt with duplicate attributes
* Add warnings when creating/updating policy with duplicate HCL attrs
* Add log warning when switchedGetPolicy finds duplicate attrs
Following operations can trigger this warning when they run into a policy
with duplicate attributes:
* replication filtered path namespaces invalidation
* policy read API
* building an ACL (for many different purposes like most authZ operations)
* looking up DR token policies
* creating a token with named policies
* when caching the policies for all namespaces during unseal
* Print log warnings when token inline policy has duplicate attrs
No unit tests on these as new test infra would have to be built on all.
Operations affected, which will now print a log warning when the retrieved
token has an inline policy with duplicate attributes:
* capabilities endpoints in sys mount
* handing events under a subscription with a token with duplicate
attrs in inline policies
* token used to create another token has duplicate attrs in inline
policies (sudo check)
* all uses of fetchACLTokenEntryAndEntity when the request uses a
token with inline policies with duplicate attrs. Almost all reqs
are subject to this
* when tokens are created with inline policies (unclear exactly how that
can happen)
* add changelog and deprecation notice
* add missing copywrite notice
* fix copy-paste mistake
good thing it was covered by unit tests
* Fix manual parsing of telemetry field in SharedConfig
This commit in the hcl library was not in the
v1.0.1-vault-5 version we're using but is
included in v1.0.1-vault-7:
e80118accb
This thing of reusing when parsing means that
our approach of manually re-parsing fields
on top of fields that have already been parsed
by the hcl annotation causes strings (maybe
more?) to concatenate.
Fix that by removing annotation. There's
actually more occurrences of this thing of
automatically parsing something that is also
manually parsing. In some places we could
just remove the boilerplate manual parsing, in
others we better remove the auto parsing, but
I don't wanna pull at that thread right now. I
just checked that all places at least fully
overwrite the automatically parsed field
instead of reusing it as the target of the
decode call. The only exception is the AOP
field on ent but that doesn't have maps or
slices, so I think it's fine.
An alternative approach would be to ensure
that the auto-parsed value is discarded,
like the current parseCache function does
note how it's template not templates
* Fix linter complaints
* Update command/base_predict.go
Co-authored-by: Mike Palmiotto <mike.palmiotto@hashicorp.com>
* address review
* remove copywrite headers
* re-add copywrite headers
* make fmt
* Update website/content/partials/deprecation/duplicate-hcl-attributes.mdx
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* Update website/content/partials/deprecation/duplicate-hcl-attributes.mdx
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* Update website/content/partials/deprecation/duplicate-hcl-attributes.mdx
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* undo changes to deprecation.mdx
* remove deprecation doc
* fix conflict with changes from main
---------
Co-authored-by: Mike Palmiotto <mike.palmiotto@hashicorp.com>
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* add automatic irrevocable lease removal features
* cleanup
* pull out ent changes
* strip out more stuff
* quiet CI screaming
* fix another test
* remove cl
* update irrevocable lease removal timing logic
* whoops
* require explicit value for disable_mlock
* set disable_mlock back to true for all docker tests
* fix build error
* update test config files
* change explicit mlock check to apply to integrated storage only.
* formatting and typo fixes
* added test for raft
* remove erroneous test
* remove unecessary doc line
* remove unecessary var
* pr suggestions
* test compile fix
* add mlock config value to enos tests
* enos lint
* update enos tests to pass disable_mlock value
* move mlock error to runtime to check for env var
* fixed mlock config detection logic
* call out mlock on/off tradeoffs to docs
* rewording production hardening section on mlock for clarity
* update error message when missing disable_mlock value to help customers with the previous default
* fix config doc error and update production-hardening doc to align with existing recommendations.
* remove extra check for mlock config value
* fix docker recovery test
* Update changelog/29974.txt
Explicitly call out that Vault will not start without disable_mlock included in the config.
Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
* more docker test experimentation.
* passing disable_mlock into test cluster
* add VAULT_DISABLE_MLOCK envvar to docker tests and pass through the value
* add missing envvar for docker env test
* upate additional docker test disable_mlock values
* Apply suggestions from code review
Use active voice.
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
---------
Co-authored-by: Kuba Wieczorek <kuba.wieczorek@hashicorp.com>
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
This is a follow-up to our initial work[0] to address RFC-5952 §4 conformance for IPv6 addresses in Vault. The initial pass focused on the vault server configuration and start-up routines. This follow-up focuses on Agent and Proxy, with a few minor improvements for server.
The approach generally mirrors the server implementation but also adds support for normalization with CLI configuration overrides.
One aspect we do not normalize currently is Agent/Proxy client creation to the Vault server with credentials taken from environment variables, as it would require larger changes to the `api` module. In practice this ought to be fine for the majority of cases.
[0]: https://github.com/hashicorp/vault/pull/29228
USGv6[0] requires implementing §4.1.1 of the NISTv6-r1 profile[1] for
IPv6-Only capabilities. This section requires that whenever Vault
displays IPv6 addresses (including CLI output, Web UI, logs, etc.) that
_all_ IPv6 addresses must conform to RFC-5952 §4 text representation
recommendations[2].
These recommendations do not prevent us from accepting RFC-4241[3] IPv6
addresses, however, whenever these same addresses are displayed they
must conform to the strict RFC-5952 §4 guidelines.
This PR implements handling of IPv6 address conformance in our
`vault server` routine. We handle conformance normalization for all
server, http_proxy, listener, seal, storage and telemetry
configuration where an input could contain an IPv6 address, whether
configured via an HCL file or via corresponding environment variables.
The approach I've taken is to handle conformance normalization at
parse time to ensure that all log output and subsequent usage
inside of Vaults various subsystems always reference a conformant
address, that way we don't need concern ourselves with conformance
later. This approach ought to be backwards compatible to prior loose
address configuration requirements, with the understanding that
going forward all IPv6 representation will be strict regardless of
what has been configured.
In many cases I've updated our various parser functions to call the
new `configutil.NormalizeAddr()` to apply conformance normalization.
Others required no changes because they rely on standard library URL
string output, which always displays IPv6 URLs in a conformant way.
Not included in this changes is any other vault exec mode other than
server. Client, operator commands, agent mode, proxy mode, etc. will
be included in subsequent changes if necessary.
[0]: https://www.nist.gov/publications/usgv6-profile
[1]: https://www.nist.gov/publications/nist-ipv6-profile
[2]: https://www.rfc-editor.org/rfc/rfc5952.html#section-4
[3]: https://www.rfc-editor.org/rfc/rfc4291
Signed-off-by: Ryan Cragun <me@ryan.ec>
This PR adds the CE plumbing and stubs for forcing agent instantiation
whenever the Vault license changes.
Resolves: VAULT-28583
Enterprise PR: hashicorp/vault-enterprise#6168
* Add option for not mounting the KV mount in --dev
* Fix whitespace I messed up during merge conflict resolution
* Feature -> Improvement
* Fix formatting for real
---------
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
* add reloading service configuration
* add changelog entry
* add tests
* fix typo
* check if config.ServiceRegistration is nil before signaling
* add changes for deregistering service on nil config with failing tests
* fix tests by decreasing reconcile_timeout + setting consul agent tokens
* fix races
* add comments in test
---------
Co-authored-by: Marc Boudreau <marc.boudreau@hashicorp.com>
Fix reloading of seal configuration when a node gains leadership.
Verify that the in-memory seal generation information is stale and only reload
seal configuration when that is the case.
When reloading seal configuration, only do it when enable_multiseal is currently
set to true, or the new configuration is attempting to set it to true.
As part of the process of becoming a leader node, check to see if the seal
configuration needs to be reloaded. Reloading may be necessary if the seal
generation information computed during start up is outdated. For example, a new
node that has just joined the cluster will have incorrect seal generation
information in memory, even if it has the correct seal configuration, since it
did not have access to the stored seal generation information.
* Add a configuration flag for enabling multiseal (Seal HA), CE side
* imports
* no quotes
* get rid of dep on ent config
* Abstract enableMultiSeal for a build time switch
* license headers
* wip
* gate physical seal gen fetch by a param
* docs tweak, remove core flag
* updates from the ent pr
* update stub
* update test fixtures for enable_multiseal
* use accessor
* add a test fixture for non-multiseal diagnose
* remove debugging crtuch
* Do handle phys seal gen info even if multiseal is off, in order to facilitate enable/disable safeties
* more enabled flag handling
* Accept seal gen info if we were previously disabled, and persist it
* update unit test
* Validation happens postUnseal, so this test is invalid
* Dont continue setting conf if seal loading fails during SIGHUP
* Update website/content/docs/configuration/seal/seal-ha.mdx
Thanks, that does sound much clearer
Co-authored-by: Jason O'Donnell <2160810+jasonodonnell@users.noreply.github.com>
* use validation if previous gen was enabled
* unit test update
* stub SetMultisealEnabled
* bring over more changes from ent
* this was an unfix
---------
Co-authored-by: Jason O'Donnell <2160810+jasonodonnell@users.noreply.github.com>
This PR flips the logic for the Request Limiter, setting it to default
disabled.
We allow users to turn on the global Request Limiter, but leave the
Listener configuration as a "disable per Listener".
Initial version of an internal plugin interface for event subscription plugins,
and an AWS SQS plugin as an example.
Co-authored-by: Tom Proctor <tomhjp@users.noreply.github.com>
* VAULT-21427 change ui references from K/V to KV
* references in docs/
* website json data
* go command errors
* replace Key/Value with Key Value
* add changelog
* update test
* update secret list header badge
* two more test updates
* release log gate if disable-gated-logs flag is set
* CL
* Update changelog/24280.txt
Co-authored-by: Josh Black <raskchanky@gmail.com>
---------
Co-authored-by: Peter Wilson <peter.wilson@hashicorp.com>
Co-authored-by: Josh Black <raskchanky@gmail.com>
It is not sufficient to check that function setSeal in server.go does not return
an "unwrap seal". For migrations away from a Shamir seal, NewCore constructor
sets up an unwrap seal by calling method adjustForSealMigration.
Factor out new method checkForSealMigration out of adjustForSealMigration so
that NewCore can verify that there won't be a migration when returning early due
to running in recovery mode.
* Refactor plugin catalog into its own package
* Fix some unnecessarily slow tests due to accidentally running multiple plugin processes
* Clean up MakeTestPluginDir helper
* Move getBackendVersion tests to plugin catalog package
* Use corehelpers.MakeTestPlugin consistently
* Fix semgrep failure: check for nil value from logical.Storage
With the introduction of the Seal High Availability feature, the presence of
multiple seals in configuration does not necessarily mean that the configuration
entails a seal migration.
Instead of checking for multiple seals, check for the presence on an "unwrap"
seal, which is only used for seal migrations.
@mitchellh suggested we fork `cli` and switch to that.
Since we primarily use the interfaces in `cli`, and the new
fork has not changed those, this is (mostly) a drop-in replacement.
A small fix will be necessary for Vault Enterprise, I believe.
* fix -log-file so that it uses the correct name and only adds timestamps on rotation
* added some tests for naming/rotation
* changelog
* revert to previous way of getting created time
* remove unused stat
* comment shuffle
* Update changelog/24297.txt
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
* Update website/content/docs/agent-and-proxy/agent/index.mdx
Update 'agent' docs page
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* Update website/content/docs/agent-and-proxy/proxy/index.mdx
Update 'proxy' docs page
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* Update website/content/docs/commands/server.mdx
Update 'server' docs page
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* fix typos
---------
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
* reload seals on SIGHUP
* add lock in SetSeals
* move lock
* use stubmaker and change wrapper finalize call
* change finalize logic so that old seals will be finalized after new seals are configured
* add changelog
* run make fmt
* fix fmt
* fix panic when reloading seals errors out
