* Document 'managed_key' key type for transit. Document new 'usages' parameter when creating a managed key in the system backend.
* Document new managed key parameters for transit managed key rotation.
* Add documentation on fetching unified CRLs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation on unified OCSP
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Clarify that OCSP requests need to be URL encoded
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Document new CRL config parameters
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Clarify notes about cross-cluster options
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
* Add docs on cross-cluster listing endpoints
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Update website/content/api-docs/secret/pki.mdx
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
* List tidy parameters in one place
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add new tidy status outputs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add docs on new tidy parameters
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* allow_forwarding_via_token syntax update
the example syntax used for `allow_forwarding_via_token` marks the option as an array when it does not need to be, this updates the format on the page to be a code block and removes the square braces
* another update to `allow_forwarding_via_token` syntax
* Add ability to clean up host keys for dynamic keys
This adds a new endpoint, tidy/dynamic-keys that removes any stale host
keys still present on the mount. This does not clean up any pending
dynamic key leases and will not remove these keys from systems with
authorized hosts entries created by Vault.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Remove dynamic keys from SSH Secrets Engine
This removes the functionality of Vault creating keys and adding them to
the authorized keys file on hosts.
This functionality has been deprecated since Vault version 0.7.2.
The preferred alternative is to use the SSH CA method, which also allows
key generation but places limits on TTL and doesn't require Vault reach
out to provision each key on the specified host, making it much more
secure.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Remove dynamic ssh references from documentation
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Remove dynamic key secret type entirely
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Clarify changelog language
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add removal notice to the website
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Update integrated-storage.mdx
The quorum paragraph shall also be updated with the table:
instead of:
"A Raft cluster of 3 nodes can tolerate a single node failure while a cluster
of 5 can tolerate 2 node failures. The recommended configuration is to either
run 3 or 5 Vault servers per cluster."
shall be:
"A Raft cluster of 3 nodes can tolerate a single node failure while a cluster
of 5 can tolerate 2 node failures. The recommended configuration is to either
run 5 or 7 Vault servers per cluster."
* Give an explicit node recommendation
---------
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
* Add Redirect for Plugin Portal -> Integration Library
* Remove Plugin Portal page & update sidebar
* Replace the Plugin Portal link to point Vault Integrations (#18897)
* Replace the Plugin Portal link to point Vault Integrations
* Update website/content/docs/partnerships.mdx
Co-authored-by: Brandon Romano <brandon@hashicorp.com>
---------
Co-authored-by: Brandon Romano <brandon@hashicorp.com>
---------
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
* Clarify error on due to unsupported EC key bits
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Remove documentation about unsupported EC/224
Resolves: #18843
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* The fields.
* UserID set, add to certificate
* Changelog.
* Fix test (set default).
* Add UserID constant to certutil, revert extension changes
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add user_ids as field for leaf signing
Presumably, this isn't necessary for CAs, given that CAs probably don't
have a user ID corresponding to them.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Support setting multiple user_ids in Subject
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Allow any User ID with sign-verbatim
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add tests for User IDs in PKI
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add docs about user_ids, allowed_user_ids
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Parallel migration (#18815)
* flagParallel sanity check
* Attempt to use ErrGroups
* Updated docs
* Allow 'start' and 'max-parallel' together
* parallel flag renamed to max-parallel
* tests for start + parallel
* Removed permit pool
* Updated docs to make it clearer that a high setting might not be honored based on storage backend setting
* System dependent max int size
* Default max-parallel 1 => 10
* Test folder/paths updated
Co-authored-by: Tomasz Pawelczak <10206601+gites@users.noreply.github.com>
Co-authored-by: Mike Palmiotto <mike.palmiotto@hashicorp.com>
* change indentation leve of cas field
* change formatting for cas_required
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
* docs/oidc: change user type recommendation for Google workspace integration
* Update website/content/docs/auth/jwt/oidc-providers/google.mdx
Co-authored-by: Calvin Leung Huang <1883212+calvn@users.noreply.github.com>
This PR relates to a feature request logged through HashiCorp commercial
support.
Vault lacks pagination in its APIs. As a result, certain list operations
can return **very** large responses. The user's chosen audit sinks may
experience difficulty consuming audit records that swell to tens of
megabytes of JSON.
In our case, one of the systems consuming audit log data could not cope,
and failed.
The responses of list operations are typically not very interesting, as
they are mostly lists of keys, or, even when they include a "key_info"
field, are not returning confidential information. They become even less
interesting once HMAC-ed by the audit system.
Some example Vault "list" operations that are prone to becoming very
large in an active Vault installation are:
auth/token/accessors/
identity/entity/id/
identity/entity-alias/id/
pki/certs/
In response, I've coded a new option that can be applied to audit
backends, `elide_list_responses`. When enabled, response data is elided
from audit logs, only when the operation type is "list".
For added safety, the elision only applies to the "keys" and "key_info"
fields within the response data - these are conventionally the only
fields present in a list response - see logical.ListResponse, and
logical.ListResponseWithInfo. However, other fields are technically
possible if a plugin author writes unusual code, and these will be
preserved in the audit log even with this option enabled.
The elision replaces the values of the "keys" and "key_info" fields with
an integer count of the number of entries. This allows even the elided
audit logs to still be useful for answering questions like "Was any data
returned?" or "How many records were listed?".
* add core state lockd eadlock detection config option v2
* add changelog
* split out NewTestCluster function to maintain build flag
* replace long func with constant
* remove line
* rename file, and move where detect deadlock flag is set
* Allow tidy to backup legacy CA bundles
With the new tidy_move_legacy_ca_bundle option, we'll use tidy to move
the legacy CA bundle from /config/ca_bundle to /config/ca_bundle.bak.
This does two things:
1. Removes ca_bundle from the hot-path of initialization after initial
migration has completed. Because this entry is seal wrapped, this
may result in performance improvements.
2. Allows recovery of this value in the event of some other failure
with migration.
Notably, this cannot occur during migration in the unlikely (and largely
unsupported) case that the operator immediately downgrades to Vault
<1.11.x. Thus, we reuse issuer_safety_buffer; while potentially long,
tidy can always be run manually with a shorter buffer (and only this
flag) to manually move the bundle if necessary.
In the event of needing to recover or undo this operation, it is
sufficient to use sys/raw to read the backed up value and subsequently
write it to its old path (/config/ca_bundle).
The new entry remains seal wrapped, but otherwise isn't used within the
code and so has better performance characteristics.
Performing a fat deletion (DELETE /root) will again remove the backup
like the old legacy bundle, preserving its wipe characteristics.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation about new tidy parameter
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add tests for migration scenarios
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Clean up time comparisons
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation on vault pki health-check
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Refer users to online docs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation for KMIP features implemented in 1.13
* Add release version for key format types
* Fix syntax
* Add supported hashing algorithms and padding methods
* Fix formatting
* Add nit picks from review feedback
* Update command/agent.go
* Attempt to only reload log level and certs
* Mimicked 'server' test for cert reload in 'agent'
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
Left out the `c.config` tweak that meant changes to lots of lines of code within the `Run` function of Agent command. :)
* Add cluster_aia_path templating variable
Per discussion with maxb, allow using a non-Vault distribution point
which may use an insecure transport for RFC 5280 compliance.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Address feedback from Max
Co-authored-by: Max Bowsher <maxbowsher@gmail.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Max Bowsher <maxbowsher@gmail.com>
* VAULT-12491 Add docs for group policy config
* VAULT-12491 typo
* VAULT-12491 typo
* VAULT-12491 Update language a bit
* VAULT-12491 Update language a bit
* VAULT-12491 Update language a bit
* Update integrated-storage.mdx
The old paragraph "The recommended deployment is either 3 or 5 servers." should match the "Minimums & Scaling" purpose from below.
It also reaffirms that, in a PRODUCTION environment, a number of 5 nodes are the minimum requirement.
A rewording is also necessary: "The recommended deployment consists in a minimum of 5 or more of servers that are odd in their total (5, 7, etc)."
* Update website/content/docs/internals/integrated-storage.mdx
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
* Return the partial success code override for all batch error types
* changelog
* docs
* Lost the actual override logic. :)
* And don't hardcode 400
* gate on success
* Rename path_config -> path_keys_config
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add config/keys to disable upserting
Transit would allow anyone with Create permissions on the encryption
endpoint to automatically create new encryption keys. This becomes hard
to reason about for operators, especially if typos are subtly
introduced (e.g., my-key vs my_key) -- there is no way to merge these
two keys afterwards.
Add the ability to globally disable upserting, so that if the
applications using Transit do not need the capability, it can be
globally disallowed even under permissive policies.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation on disabling upsert
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Update website/content/api-docs/secret/transit.mdx
Co-authored-by: tjperry07 <tjperry07@users.noreply.github.com>
* Update website/content/api-docs/secret/transit.mdx
Co-authored-by: tjperry07 <tjperry07@users.noreply.github.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: tjperry07 <tjperry07@users.noreply.github.com>
* VAULT-11510 Vault Agent can start listeners without caching
* VAULT-11510 fix order of imports
* VAULT-11510 changelog
* VAULT-11510 typo and better switch
* VAULT-11510 update name
* VAULT-11510 New api_proxy stanza to configure API proxy
* VAULT-11510 First pass at API Proxy docs
* VAULT-11510 nav data
* VAULT-11510 typo
* VAULT-11510 docs update
* Allow templating of cluster-local AIA URIs
This adds a new configuration path, /config/cluster, which retains
cluster-local configuration. By extending /config/urls and its issuer
counterpart to include an enable_templating parameter, we can allow
operators to correctly identify the particular cluster a cert was
issued on, and tie its AIA information to this (cluster, issuer) pair
dynamically.
Notably, this does not solve all usage issues around AIA URIs: the CRL
and OCSP responder remain local, meaning that some merge capability is
required prior to passing it to other systems if they use CRL files and
must validate requests with certs from any arbitrary PR cluster.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation about templated AIAs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add tests
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* AIA URIs -> AIA URLs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* issuer.AIAURIs might be nil
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Allow non-nil response to config/urls
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Always validate URLs on config update
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Ensure URLs lack templating parameters
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Review feedback
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Work to unify log-file for agent/server and add rotation
* Updates to rotation code, tried to centralise the log config setup
* logging + tests
* Move LogFile to ShareConfig in test
* Docs
Per conversation on Slack with Nick.
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
* New PKI API to generate and sign a CRL based on input data
- Add a new PKI API that allows an end-user to feed in all the
information required to generate and sign a CRL by a given issuer.
- This is pretty powerful API allowing an escape hatch for 3rd parties
to craft customized CRLs with extensions based on their individual
needs
* Add api-docs and error if reserved extension is provided as input
* Fix copy/paste error in Object Identifier constants
* Return nil on errors instead of partially filled slices
* Add cl
* add compatibility info to consul service reg docs
* fix alert formatting
* add consul dataplane compatibility partial
* add compat partial to more consul doc pages
* fix links
* Add crl list capabilities to cert auth
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add docs on cert auth CRL listing
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add test for cert auth listing
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add new PKI api to combine and sign different CRLs from the same issuer
- Add a new PKI api /issuer/<issuer ref>/resign-crls that will allow
combining and signing different CRLs that were signed by the same
issuer.
- This allows external actors to combine CRLs into a single CRL across
different Vault clusters that share the CA certificate and key material
such as performance replica clusters and the primary cluster
* Update API docs
* PR Feedback - Delta CRL rename
* Update to latest version of main
* PR Feedback - Get rid of the new caEntry struct
* Address PR feedback in api-docs and PEM encoded response
* Add known issue about PKI secrets engine with Consul
* Added KB article URL
* Update website/content/docs/secrets/pki/index.mdx
Co-authored-by: Jared Kirschner <85913323+jkirschner-hashicorp@users.noreply.github.com>
Co-authored-by: Jared Kirschner <85913323+jkirschner-hashicorp@users.noreply.github.com>
- Within the table specifying the various paths to generate a CSR
in the PKI docs, the new issuers based api has a typo in it missing
the issuers/ prefix.
- Brought to our attention by Chelsea and Claire, thanks!
When renaming the header to Set Revocation Configuration, we broke
bookmarks. Add in the named anchor so the old bookmarks and links still
work.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Thanks to Khai Tran for identifying that syslogging has a lower limit
on message size and sometimes large CRLs can hit that limit.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add clarifications on revocation
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Talk about rationale for separating roots from intermediates
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Added documentation for Introspection API
* Edit hyperlink in index doc
* Added the path to the nav file
* Edited some mispelled words
* Fix deployment issue. Change link in nav file
* Edit the router mdx and add response values
* Edit nav doc
* Changed hyperlink, changed response to json, changed some wording
* Remove requirement that the endpoint is off by default
* Update website/content/api-docs/system/inspect/router.mdx
Co-authored-by: Josh Black <raskchanky@users.noreply.github.com>
* Update website/content/api-docs/system/inspect/router.mdx
Co-authored-by: Josh Black <raskchanky@users.noreply.github.com>
* Update website/content/api-docs/system/inspect/index.mdx
Co-authored-by: Josh Black <raskchanky@users.noreply.github.com>
Co-authored-by: Josh Black <raskchanky@users.noreply.github.com>
* Started work on adding log-file support to Agent
* Allow log file to be picked up and appended
* Use NewLogFile everywhere
* Tried to pull out the config aggregation from Agent.Run
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
The current behaviour is to only add mount paths into the generated `opeanpi.json` spec if a `generic_mount_paths` flag is added to the request. This means that we would have to maintain two different `openapi.json` files, which is not ideal. The new solution in this PR is to add `{mount_path}` into every path with a default value specified:
```diff
-- "/auth/token/accessors/": {
++ "/auth/{mount_path}/accessors/": {
"parameters": [
{
"name": "mount_path",
"description": "....",
"in": "path",
"schema": {
"type": "string",
++ "default": "token"
}
}
],
```
Additionally, fixed the logic to generate the `operationId` (used to generate method names in the code generated from OpenAPI spec). It had a bug where the ID had `mountPath` in it. The new ID will look like this:
```diff
-- "operationId": "listAuthMountpathAccessors",
++ "operationId": "listTokenAccessors",
```
* clarify that init recovery options are only available for auto unseal
* add some language consistency
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com>
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com>
* Add automatic tidy of expired issuers
To aid PKI users like Consul, which periodically rotate intermediates,
and provided a little more consistency with older versions of Vault
which would silently (and dangerously!) replace the configured CA on
root/intermediate generation, we introduce an automatic tidy of expired
issuers.
This includes a longer safety buffer (1 year) and logging of the
relevant issuer information prior to deletion (certificate contents, key
ID, and issuer ID/name) to allow admins to recover this value if
desired, or perform further cleanup of keys.
From my PoV, removal of the issuer is thus a relatively safe operation
compared to keys (which I do not feel comfortable removing) as they can
always be re-imported if desired. Additionally, this is an opt-in tidy
operation, not enabled by default. Lastly, most major performance
penalties comes with lots of issuers within the mount, not as much
large numbers of keys (as only new issuer creation/import operations are
affected, unlike LIST /issuers which is a public, unauthenticated
endpoint).
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add test for tidy
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add docs on tidy of issuers
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Restructure logging
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add missing fields to expected tidy output
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Fix a typo around custom-metadata in kv put docs
There is a missing dash before 'custom-metadata':
$ vault kv metadata put custom-metadata="foo=bar" secret/hub/config-demo
Too many arguments (expected 1, got 2)
$ vault kv metadata put -custom-metadata="foo=bar" secret/hub/config-demo
Success! Data written to: secret/metadata/hub/config-demo
Signed-off-by: Michele Baldessari <michele@acksyn.org>
* Update website/content/docs/commands/kv/metadata.mdx
Signed-off-by: Michele Baldessari <michele@acksyn.org>
Co-authored-by: Alexander Scheel <alexander.m.scheel@gmail.com>
* Correctly preserve other issuer config params
When setting a new default issuer, our helper function would overwrite
other parameters in the issuer configuration entry. However, up until
now, there were none.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add new parameter to allow default to follow new
This parameter will allow operators to have the default issuer
automatically update when a new root is generated or a single issuer
with a key (potentially with others lacking key) is imported.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Storage migration tests fail on new members
These internal members shouldn't be tested by the storage migration
code, and so should be elided from the test results.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Follow new issuer on root generation, import
This updates the two places where issuers can be created (outside of
legacy CA bundle migration which already sets the default) to follow
newly created issuers when the config is set.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add test for new default-following behavior
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Specifying only `args` will just append them to the container image's
entrypoint instead of replacing it. Setting command overrides the
entrypoint, and args is then appended to the command.
* Add new API to PKI to list revoked certificates
- A new API that will return the list of serial numbers of
revoked certificates on the local cluster.
* Add cl
* PR feedback
* Ensure correct write ordering in rebuildIssuersChains
When troubleshooting a recent migration failure from 1.10->1.11, it was
noted that some PKI mounts had bad chain construction despite having
valid, chaining issuers. Due to the cluster's leadership trashing
between nodes, the migration logic was re-executed several times,
partially succeeding each time. While the legacy CA bundle migration
logic was written with this in mind, one shortcoming in the chain
building code lead us to truncate the ca_chain: by sorting the list of
issuers after including non-written issuers (with random IDs), these
issuers would occasionally be persisted prior to storage _prior_ to
existing CAs with modified chains.
The migration code carefully imported the active issuer prior to its
parents. However, due to this bug, there was a chance that, if write to
the pending parent succeeded but updating the active issuer didn't, the
active issuer's ca_chain field would only contain the self-reference and
not the parent's reference as well. Ultimately, a workaround of setting
and subsequently unsetting a manual chain would force a chain
regeneration.
In this patch, we simply fix the write ordering: because we need to
ensure a stable chain sorting, we leave the sort location in the same
place, but delay writing the provided referenceCert to the last
position. This is because the reference is meant to be the user-facing
action: without transactional write capabilities, other chains may
succeed, but if the last user-facing action fails, the user will
hopefully retry the action. This will also correct migration, by
ensuring the subsequent issuer import will be attempted again,
triggering another chain build and only persisting this issuer when
all other issuers have also been updated.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Remigrate ca_chains to fix any missing issuers
In the previous commit, we identified an issue that would occur on
legacy issuer migration to the new storage format. This is easy enough
to detect for any given mount (by an operator), but automating scanning
and remediating all PKI mounts in large deployments might be difficult.
Write a new storage migration version to regenerate all chains on
upgrade, once.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog entry
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add issue to PKI considerations documentation
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Correct %v -> %w in chain building errs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
This article seems to use the terms "shares" and "shards" interchangeably to describe the parts in which the secret is split under SSS.
While both seem to be correct, sticking to one term would save a newbie reader (like myself) the confusion.
Since the Wikipedia article that's linked in this article only mentions "shares" and the CLI flags (for recovery keys) also use `-shares`, I opted for that.
* Return revocation info within existing certs/<serial> api
- The api already returned both the certificate and a revocation_time
field populated. Update the api to return revocation_time_rfc3339
as we do elsewhere and also the issuer id if it was revoked.
- This will allow callers to associate a revoked cert with an issuer
* Add cl
* PR feedback (docs update)
* Update signed-ssh-certificates.mdx
Add a pointer to the doc regarding reading back the pub key with the CLI
* Update website/content/docs/secrets/ssh/signed-ssh-certificates.mdx
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Clarify when -format=raw fails
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Document Vault read's new -format=raw mode
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add raw format to usage, completion
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add missing support for raw format field printing
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Prohibit command execution with wrong formatter
This allows us to restrict the raw formatter to only commands that
understand it; otherwise, when running `vault write -format=raw`, we'd
actually hit the Vault server, but hide the output from the user. By
switching this to a flag-parse time check, we avoid running the rest of
the command if a bad formatter was specified.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Docs: API secret/ssh clarity on Create & Update
Added clarity notes on required permissions (`update` & `create`) that's otherwise not obvious without experience of other mounts that have requirements for similar ACL to manage. Resolves#9888.
* Update website/content/api-docs/secret/ssh.mdx
Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
* Update website/content/api-docs/secret/ssh.mdx
Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
* Docs: API secret/ssh clarity on Create & Update...
Reduced text (-1 line) further to feedback from @benashz; retaining details on `create` vs `update` difference as per [API transit method that calls this out too.](https://www.vaultproject.io/api-docs/secret/transit#encrypt-data)
* trigger ci
Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
* Docs: API overview text clarity & kv2 mention... #16746
Corrected text and terminology. Relates to #6378 & should allow for closure of that issue too.
<img width="1158" alt="Screenshot 2022-08-16 at 19 23 20" src="https://user-images.githubusercontent.com/974854/184941452-2b2c680a-b6d5-4db6-85aa-e5dc672499f6.png">
* Trigger CI
* Update website/content/api-docs/index.mdx
Co-authored-by: Ben Ash <32777270+benashz@users.noreply.github.com>
* Update website/content/api-docs/index.mdx
Co-authored-by: Ben Ash <32777270+benashz@users.noreply.github.com>
* Update website/content/api-docs/index.mdx
Co-authored-by: Ben Ash <32777270+benashz@users.noreply.github.com>
* Update website/content/api-docs/index.mdx
Co-authored-by: Ben Ash <32777270+benashz@users.noreply.github.com>
* Update website/content/api-docs/index.mdx
Co-authored-by: Ben Ash <32777270+benashz@users.noreply.github.com>
* Updated based on feedback.
* Docs: API overview text clarity & kv2 mention...
Added KV2 explict further to feedback from @benashz.
Also:
- Adjusted very first paragraph a bit.
- improved grammer and over use of `via` and `to` in certian places.
Co-authored-by: Zlaticanin <zlaticaninmilena@gmail.com>
Co-authored-by: Ben Ash <32777270+benashz@users.noreply.github.com>
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
Extend the documentation the API endpoint '/ssh/issue/:name' (added
in #15561 with v1.12.0) and '/ssh/issue/:name':
- Be more specific that the issued certificate uses the defaults
given of the role at the given endpoint; and that it is subject
to the limitations configured in this role.
- Note that the endpoint /ssh/issue/:name is available with v1.12+.
- Make it more clear that the generated credentials are only returned
but not stored by Vault (not just the generated private key).
* Add support for PKCSv1_5_NoOID signatures
This assumes a pre-hashed input has been provided to Vault, but we do
not write the hash's OID into the signature stream. This allows us to
generate the alternative PKCSv1_5_NoOID signature type rather than the
existing PKCSv1_5_DERnull signature type we presently use.
These are specified in RFC 3447 Section 9.2.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Exclude new none type from PSS based tests
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add tests for PKCS#1v1.5 signatures
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add patch support to CLI
This is based off the existing write command, using the
JSONMergePatch(...) API client method rather than Write(...), allowing
us to update specific fields.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add documentation on PATCH support
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
