It was determined that it would be better to have these changes alert
the docs team. Additional guidance is in place to not approve docs+code
PRs ahead of code review.
This reverts commit 6d16840f605c1b58ce0b572274edf96c6d0e0b7f.
* remove mount accessor from MFA config
* Update login_mfa_duo_test.go
* DUO test with entity templating
* using identitytpl.PopulateString to perform templating
* minor refactoring
* fixing fmt failures in CI
* change username format to username template
* fixing username_template example
* Full secret path in table output of get and put
* Add path output to KV patch and metadata get
* Add changelog
* Don't print secret path for kv-v1
* Make more readable
* Switch around logic to not swallow error
* Add test for secret path
* Fix metadata test
* Add unit test for padequalsigns
* Remove wonky kv get tests
* Add support for PROXY protocol v2 in TCP listener
I did not find tests for this so I added one trying to cover different
configurations to make sure I did not break something. As far as I know,
the behavior should be exactly the same as before except for one thing
when proxy_protocol_behavior is set to "deny_unauthorized", unauthorized
requests were previously silently reject because of https://github.com/armon/go-proxyproto/blob/7e956b284f0a/protocol.go#L81-L84
but it will now be logged.
Also fixes https://github.com/hashicorp/vault/issues/9462 by adding
support for `PROXY UNKNOWN` for PROXY protocol v1.
Closes https://github.com/hashicorp/vault/issues/3807
* Add changelog
* Add documentation for Managed Keys
- Add concept, sys/api and pki updates related to managed keys
* Review feedback
- Reworked quite a bit of the existing documentation based on feedback
and a re-reading
- Moved the managed keys out of the concepts section and into the
enterprise section
* Address broken links and a few grammar tweaks
* add documentation for AWS KMS managed keys
* a couple small fixes
* # Conflicts:
# website/content/api-docs/secret/pki.mdx
# website/content/api-docs/system/managed-keys.mdx
# website/content/docs/enterprise/managed-keys.mdx
* docs updates
* # Conflicts:
# sdk/version/version_base.go
# vault/seal_autoseal_test.go
# website/content/api-docs/system/managed-keys.mdx
# website/content/docs/enterprise/managed-keys.mdx
* remove endpoint env var
* Document Azure Key Vault parameters for managed keys.
* docs changes for aws kms managed keys
Co-authored-by: Steve Clark <steven.clark@hashicorp.com>
Co-authored-by: Victor Rodriguez <vrizo@hashicorp.com>
* add mount move docs
* add missed word
* Update website/content/api-docs/system/remount.mdx
Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
* one clarification
* docs changes from feedback
* couple things i missed
Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
As reported by Steve Clark, building an intermediate mount in PKI (and
calling /intermediate/set-signed) results in a duplicate intermediate CA
certificate in the full chain output (ca_chain field of the
/cert/ca_chain API endpoint response).
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* fix no data empty states
* add comment
* handle error in component
* adds tests for empty state template
* tidy and fix tests
* Empty state for current tab (#14319)
* update ci.hcl to remove 1.6.x and add in 1.10.x (#14310)
* Fix autoseal health check race by passing metrics sink in CoreConfig (#14196)
* Add empty state for current tab, config off, no read permissions on config
Co-authored-by: Hridoy Roy <roy@hashicorp.com>
Co-authored-by: Scott Miller <smiller@hashicorp.com>
* update selector
* fix test
* remove helper
Co-authored-by: Chelsea Shaw <82459713+hashishaw@users.noreply.github.com>
Co-authored-by: Hridoy Roy <roy@hashicorp.com>
Co-authored-by: Scott Miller <smiller@hashicorp.com>
* Add warning when generate_lease=no_store=true
When no_store=true, the value of generate_lease is ignored completely
(and set to false). This means that when generate_lease=true is
specified by the caller of the API, it is silently swallowed. While
changing the behavior could break callers, setting a warning on the
response (changing from a 204->200 in the process) seems to make the
most sense.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
