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
- 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>
* 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>
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>
* 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>
* 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
* 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)
* 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>
* Allow passing AssociatedData factories in keysutil
This allows the high-level, algorithm-agnostic Encrypt/Decrypt with
Factory to pass in AssociatedData, and potentially take multiple
factories (to allow KMS keys to work). On AEAD ciphers with a relevant
factory, an AssociatedData factory will be used to populate the
AdditionalData field of the SymmetricOpts struct, using it in the AEAD
Seal process.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add associated_data to Transit Encrypt/Decrypt API
This allows passing the associated_data (the last AD in AEAD) to
Transit's encrypt/decrypt when using an AEAD cipher (currently
aes128-gcm96, aes256-gcm96, and chacha20-poly1305). We err if this
parameter is passed on non-AEAD ciphers presently.
This associated data can be safely transited in plaintext, without risk
of modifications. In the event of tampering with either the ciphertext
or the associated data, decryption will fail.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add to documentation
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Allow OCSP to use issuer's RevocationSigAlgo
When an issuer specifies a RevocationSigAlgo, we should largely follow
this for both CRLs and OCSP. However, x/crypto/ocsp lacks support for
PSS signatures, so we drop these down to PKCS#1v1.5 instead.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add warning when issuer has PSS-based RevSigAlgo
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add note about OCSP and PSS support
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* PKI: Add support for signature_bits param to the intermediate/generate api
- Mainly to work properly with GCP backed managed keys, we need to
issue signatures that would match the GCP key algorithm.
- At this time due to https://github.com/golang/go/issues/45990 we
can't issue PSS signed CSRs, as the libraries in Go always request
a PKCS1v15.
- Add an extra check in intermediate/generate that validates the CSR's
signature before providing it back to the client in case we generated
a bad signature such as if an end-user used a GCP backed managed key
with a RSA PSS algorithm.
- GCP ignores the requested signature type and always signs with the
key's algorithm which can lead to a CSR that says it is signed with
a PKCS1v15 algorithm but is actually a RSA PSS signature
* Add cl
* PR feedback
* Update docs for new test/sign params for managed key api
- The existing test/sign managed key api now has two new api params
allowing an operator to specify to use RSA PSS signatures (use_pss)
and to specify the hashing algorithm to use (hash_algorithm)
* Remove duplicate GCP signing algo entry
* Formatting nits and mention the key_ring for GCP needs to exist prior to usage
* Add some additional GCP environment vars
* docs/api-docs for Redis
* update doc
* add navigation to the docs
* Update website/content/api-docs/secret/databases/redis.mdx
Co-authored-by: Austin Gebauer <34121980+austingebauer@users.noreply.github.com>
* Update website/content/docs/secrets/databases/redis.mdx
Co-authored-by: Austin Gebauer <34121980+austingebauer@users.noreply.github.com>
* update setup list and lang tag for shell code blocks
* update language tag
* update based on suggestions
* update docs to include tls params
* add plugin to the plugin portal doc
* add -
* update api-docs-nav-data.json
* update field name
* Update website/content/docs/secrets/databases/redis.mdx
Co-authored-by: Robert <17119716+robmonte@users.noreply.github.com>
* Update website/content/docs/secrets/databases/redis.mdx
Co-authored-by: Robert <17119716+robmonte@users.noreply.github.com>
* Update website/content/docs/secrets/databases/redis.mdx
Co-authored-by: Robert <17119716+robmonte@users.noreply.github.com>
* Update website/content/docs/secrets/databases/redis.mdx
Co-authored-by: Robert <17119716+robmonte@users.noreply.github.com>
* Update website/content/api-docs/secret/databases/redis.mdx
Co-authored-by: Robert <17119716+robmonte@users.noreply.github.com>
* update docs
Co-authored-by: Austin Gebauer <34121980+austingebauer@users.noreply.github.com>
Co-authored-by: Robert <17119716+robmonte@users.noreply.github.com>
* add api docs for transform byok endpoints
* add byok description to transform index page
* fix merge conflicts
* remove import_version for FPE
* text edits and add note about convergent tokenization
* add note for convergent tokenization
