* 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>
* Add regression test for default CRL expiry
Also fixes a bug w.r.t. upgrading older entries and missing the Delta
Rebuild Interval field, setting it to the default.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add changelog for earlier PR
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@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>
* adds error handling to auth-jwt component for missing roles and fixes bug where role wasn't being retained when using alternate oidc mount path at login
* fixes jwt login bug from auth mount tabs and adds test
* updates okta-number-challenge success value to arg in template
* adds changelog entry
* fixes issues logging in manually with jwt
* reverts mistaken change
* Store login MFA secret with tokenhelper
* Clean up and refactor tokenhelper paths
* Refactor totp test code for re-use
* Add login MFA command tests
* Use longer sleep times and sha512 for totp test
* Add changelog
Vault's new TLS devvault mode has two nits with certificate
construction:
1. The CA doesn't need to include any SANs, as these aren't checked.
Technically this means the CA could be reused as a leaf certificate
for the one specified IP SAN, which is less desirable.
2. Add hostname to SANs in addition to CNs. This is a best practice, as
(when the CN is a hostname), it is preferable to have everything in
SANs as well.
Neither of these are major changes.
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>
This appears to be due to a CI change that resulted in different user
IDs between the host and the container image.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* wip
* work in progress
* pki-role-form-test
* clean up
* radio-select-ttl-or-string test
* clean up
* add yielded check
* 12 to 13
* add pki-key-usage test
* remove meep
* key-params test
* clean up
* clean up
* pr comments
* 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>
* [CI-only] Update RedHat registry tag
There are a few changes being made to RedHat's registry on October 20, 2022 that affect the way images need to be tagged prior to being pushed to the registry. This PR changes the tag to conform to the new standard.
We have other work queued up in crt-workflows-common and actions-docker-build to support the other required changes.
This PR should be merged to `main` and all release branches on or after October 20, 2022, and MUST be merged before your next production release. Otherwise, the automation to push to the RedHat registry will not work.
----
A detailed list of changes shared from RedHat (as an FYI):
The following changes will occur for container certification projects that leverage the Red Hat hosted registry [[registry.connect.redhat.com](http://registry.connect.redhat.com/)] for image distribution:
- All currently published images are migrating to a NEW, Red Hat hosted quay registry. Partners do not have to do anything for this migration, and this will not impact customers. The registry will still utilize [registry.connect.redhat.com](http://registry.connect.redhat.com/) as the registry URL.
- The registry URL currently used to push, tag, and certify images, as well as the registry login key, will change. You can see these changes under the “Images” tab of the container certification project. You will now see a [quay.io](http://quay.io/) address and will no longer see [scan.connect.redhat.com](http://scan.connect.redhat.com/).
- Partners will have the opportunity to auto-publish images by selecting “Auto-publish” in the Settings tab of your certification project. This will automatically publish images that pass all certification tests.
- For new container image projects, partners will have the option to host within their own chosen image registry while using [registry.connect.redhat.com](http://registry.connect.redhat.com/) as a proxy address. This means the end user can authenticate to the Red Hat registry to pull a partner image without having to provide additional authentication to the partner’s registry.
* docker: update redhat_tag
Co-authored-by: Sam Salisbury <samsalisbury@gmail.com>
Since 1.9 k8s auth method supports setting Name reported by auth method to Service Account name which is not reflected in this doc
Co-authored-by: Tom Proctor <tomhjp@users.noreply.github.com>
