* Ignore nonces when encrypting without convergence or with convergence versions > 1
* Honor nonce use warning in non-FIPS modes
* Revert "Honor nonce use warning in non-FIPS modes"
This reverts commit 2aee3dbdc1.
* Add a test func that removes a nonce when not needed
* err out rather than ignore the nonce
* Alter unit test to cover, also cover convergent version 3
* More unit test work
* Fix test 14
* changelog
* tests not already in a nonce present path
* Update unit test to not assume warning when nonce provided incorrectly
* remove unused test field
* Fix auto-squash events experiments
When #22835 was merged, it was auto-squashed, so the `experiments`
import was removed, but the test still referenced it.
This removes the (now unnecessary) experiment from the test.
* Allow nonces for managed keys, because we have no way of knowing if the backing cipher/mode needs one
---------
Co-authored-by: Christopher Swenson <christopher.swenson@hashicorp.com>
* Also makes plugin directory optional when registering container plugins
* And threads plugin runtime settings through to plugin execution config
* Add runsc to github runner for plugin container tests
Subscribing to events through a WebSocket now support boolean
expressions to filter only the events wanted based on the fields
* `event_type`
* `operation`
* `source_plugin_mount`
* `data_path`
* `namespace`
Example expressions:
These can be passed to `vault events subscribe`, e.g.,:
* `event_type == abc`
* `source_plugin_mount == secret/`
* `event_type != def and operation != write`
```sh
vault events subscribe -filter='source_plugin_mount == secret/' 'kv*'
```
The docs for the `vault events subscribe` command and API endpoint
will be coming shortly in a different PR, and will include a better
specification for these expressions, similar to (or linking to)
https://developer.hashicorp.com/boundary/docs/concepts/filtering
* Fix transit panic with invalid PEM
When an invalid (non-PEM) public key is given to Transit's import, this
fails with a panic in server logs:
2023-09-05T08:11:11.526-0400 [INFO] http: panic serving 127.0.0.1:42414: runtime error: invalid memory address or nil pointer dereference
goroutine 950 [running]:
net/http.(*conn).serve.func1()
/usr/local/go/src/net/http/server.go:1868 +0xb9
panic({0x8371620?, 0x1050b390?})
/usr/local/go/src/runtime/panic.go:920 +0x270
github.com/hashicorp/vault/sdk/helper/keysutil.(*Policy).ImportPublicOrPrivate(0xc003fff440, {0xaf02918, 0xc004509920}, {0xaf03670, 0xc0032e4180}, {0xc004532ea0, 0x188, 0x1a0}, 0x0, {0xae7f5e0, ...})
/home/cipherboy/GitHub/cipherboy/vault/sdk/helper/keysutil/policy.go:1538 +0x687
github.com/hashicorp/vault/sdk/helper/keysutil.(*LockManager).ImportPolicy(0xc001a29410, {0xaf02918, 0xc004509920}, {{0xaf03670, 0xc0032e4180}, {0xc003eb5ab5, 0xb}, 0x3, 0x0, 0x0, ...}, ...)
/home/cipherboy/GitHub/cipherboy/vault/sdk/helper/keysutil/lock_manager.go:517 +0x38a
This is unfortunate and doesn't reveal the cause of the failure: input
was not provided in PEM format, per docs.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Fix additional PEM decode without error check
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>
Implements running plugins in containers to give them some degree
of isolation from the main Vault process and other plugins. It only
supports running on Linux initially, where it is easiest to manage unix
socket communication across the container boundary.
Additionally
* Adds -env arg to vault plugin register.
* Don't return env from 'vault plugin info'
Historically it's been omitted, and it could conceivably have secret information in
it, so if we want to return it in the response, it should probably only be via explicit
opt-in. Skipping for now though as it's not the main purpose of the commit.
* reduce calls to DetermineRoleFromLoginRequest from 3 to 1 for aws auth method
* change ordering of LoginCreateToken args
* replace another determineRoleFromLoginRequest function with role from context
* add changelog
* Check for role in context if not there make call to DeteremineRoleFromLoginRequest
* move context role check below nanmespace check
* Update changelog/22583.txt
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
* revert signature to same order
* make sure resp is last argument
* retrieve role from context closer to where role variable is needed
* remove failsafe for role in mfa login
* Update changelog/22583.txt
---------
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
Biggest change: we rename `Send` to `SendEvent` in `logical.EventSender`..
Initially we picked `Send` to match the underlying go-eventlogger
broker's `Send` method, and to avoid the stuttering of `events.SendEvent`.
However, I think it is more useful for the `logical.EventSender`
interface to use the method `SendEvent` so that, for example,
`framework.Backend` can implement it.
This is a relatively change now that should not affect anything
except the KV plugin, which is being fixed in another PR.
Another change: if the `secret_path` metadata is present, then
the plugin-aware `EventBus` will prepend it with the plugin mount.
This allows the `secret_path` to be the full path to any referenced
secret.
This change is also backwards compatible, since this field was not
present in the KV plugin. (It did use the slightly different `path`
field, which we can keep for now.)
* Remove note
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Remove duplicate curve check
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Remove CreateOperation from new Transit X.509 endpoints
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add test to validate key matching works
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* setup initial boilerplate code for sign csr endpoint
* add function to sign csr
* working version of sign csr endpoint
* improving errors for csr create and sign endpoint
* initial implementation for import leaf certificate endpoint
* check if more than one certificate was provided in the ceritificate chain
* improve validate cert public key matches transit key
* convert provided cert chain from PEM to DER so it can be parsed by
x509.ParseCertificates and fixing other bugs
* fix creation of csr from csrTemplate
* add missing persist of certificate chain after validations in set-certificate endpoint
* allow exporting a certificate-chain
* move function declaration to end of page
* improving variable and function names, removing comments
* fix certificate chain parsing - work in progress
* test for signCsr endpoint
* use Operations instead of Callbacks in framework.Path
* setup test for set-certificate endpoint
fix problems with sign-csr endpoint returning base64
* finish set-certificate endpoint test
* use public key KeyEntry fields instead of retrieving public key from private
* improve error message and make better distinction between client and server error
also moved check of key types before checking if key match to endpoint handler
* check if private key has been imported for key version selected when signing a csr
* improve errors
* add endpoint description and synopsis
* fix functions calls in backend as function names changed
* improve import cert chain test
* trim whitespaces on export certificate chain
* changelog
* pass context from handler function to policy Persist
* make fmt run
* fix: assign returned error from PersistCertificateChain to err so it can be evaluated
* additional validations and improvements to parseCertificateChain function
* add validation to check if there is only one certificate in the certificate chain and it is in the first position
* import cert chain test: move creation of cluster to exported test function
* move check of end-cert pub key algorithm and key transit algorithm match into a separate function
* test export certificate chain
* Update sdk/helper/keysutil/policy.go
Co-authored-by: Alexander Scheel <alexander.m.scheel@gmail.com>
* fix validateLeafCertPosition
* reject certificate actions on policies that allow key derivation and remove derived checks
* return UserError from CreateCSR SDK function as 400 in transit API handler
* add derived check for ED5519 keys on CreateCSR SDK func
* remove unecessary calls of x509.CreateCertificateRequest
* move validate key type match back into SDK ValidateLeafCertMatch function
* add additional validations (ValidateLeafCertKeyMatch, etc) in SDK PersistCertificateChain function
* remove uncessary call of ValidateLeafCertKeyMatch in parseImportCertChainWrite
* store certificate chain as a [][]byte instead of []*x509.Certificate
* include persisted ca chain in import cert-chain response
* remove NOTE comment
* allow exporting cert-chain even if exportable is set as false
* remove NOTE comment
* add certifcate chain to formatKeyPublic if present
also added an additional check to validate if field is added when
certchain is present
---------
Co-authored-by: Alexander Scheel <alexander.m.scheel@gmail.com>
* Initial oss-patch apply
* Added changelog
* Renamed changelog txt
* Added the imports to the handler file
* Added a check that no two ports are the same, and modified changelog
* Edited go sum entry
* Tidy up using go mod
* Use strutil instead
* Revert go sum and go mod
* Revert sdk go sum
* Edited go.sum to before
* Edited go.sum again to initial
* Revert changes
* Adding explicit MPL license for sub-package.
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Adding explicit MPL license for sub-package.
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Updating the license from MPL to Business Source License.
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at www.hashicorp.com/licensing-faq, and details of the license at www.hashicorp.com/bsl.
* add missing license headers
* Update copyright file headers to BUS-1.1
* Fix test that expected exact offset on hcl file
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: Sarah Thompson <sthompson@hashicorp.com>
Co-authored-by: Brian Kassouf <bkassouf@hashicorp.com>
* Refactor sign-intermediate API response
- Allow the sign-intermediate response handling code to be shared
across different API calls.
* Add missing cieps.go
* Migrate protobuf generation to Buf
Buf simplifies the generation story and allows us to lean
into other features in the Buf ecosystem, such as dependency
management, linting, breaking change detection, formatting
and remote plugins.
* Format all protobuf files with buf
Also add a CI job to ensure formatting remains consistent
* Add CI job to warn on proto generate diffs
Some files were not regenerated with the latest version
of the protobuf binary. This CI job will ensure we are always
detect if the protobuf files need regenerating.
* Add CI job for linting protobuf files
* add APILockShouldBlockRequest to backend proto
* make proto
* add APILockShouldBlockRequest to system view
* Revert "make proto"
This reverts commit 7f33733f185e8a7419590d82150e85abdcc5e707.
* Revert "add APILockShouldBlockRequest to backend proto"
This reverts commit a3bf41f7f2a0811dd323fbff4da45a582c942f2b.
* move APILockShouldBlockRequest to extended sys view
* add changelog entry
In my recent #21942, I overlooked the need to sort another part of the
OpenAPI document to ensure stable output.
I've also removed `strings.ToLower()` from the code I copied from, as
this code is sorting Vault API parameter names, which are all lowercase
anyway!
* OpenAPI: Define default response structure for ListOperations
Almost all Vault ListOperation responses have an identical response
schema. Update the OpenAPI generator to know this, and remove a few
instances where that standard response schema had been manually
copy/pasted into place in individual endpoints.
* changelog
* Only render StandardListResponse schema, if an operation uses it
* Teach the response schema validation test helper about the default list schema too
---------
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com>
* OpenAPI: Fix generation of correct fields
Currently, the OpenAPI generator logic is wrong about how it maps from
Vault framework fields to OpenAPI. This manifests most obviously with
endpoints making use of `framework.OptionalParamRegex` or similar
regex-level optional path parameters, and results in various incorrect
fields showing up in the generated request structures.
The fix is a bit complicated, but in essence is just rewriting the
OpenAPI logic to properly parallel the real request processing logic.
With these changes:
* A path parameter in an optional part of the regex, no longer gets
erroneously treated as a body parameter when creating OpenAPI
endpoints that do not include the optional parameter.
* A field marked as `Query: true` no longer gets incorrectly skipped
when creating OpenAPI `POST` operations.
* changelog
* Add missing `Query: true` metadata to API definitions
Also improve the documentation comment for `Query` to guide people better how they should be setting `Query` in the future.
Endpoints affected:
- auth/approle/role/{role_name}/secret-id/destroy
- auth/approle/role/{role_name}/secret-id-accessor/destroy
- auth/token/lookup
- auth/token/lookup-self
- sys/internal/specs/openapi
- sys/wrapping/lookup
- identity/oidc/provider/{name}/authorize
There are also endpoints in the `aws` and `gcp` secrets engines which need the same treatment in their own PRs.
When working on the `auth/token/lookup-self` path, I discovered that it
had a parameter which was completely pointless - it was even documented
as unused. It only existed because the `auth/token/lookup-self` code
path was implemented by bodging the current token into the request data
and passing control to the `auth/token/lookup` handler directly -
instead of just factoring out the common code to a reusable function -
so I fixed that whilst I was there.
Note that two of the affected endpoints currently have one form of their
OpenAPI operation ID set to something mentioning "with-parameters":
- identity/oidc/provider/{name}/authorize
- sys/internal/specs/openapi
These operation IDs should be changed, as they perpetuate
a misunderstanding - both read (GET) and update (POST/PUT) forms of
these APIs are **equally** capable of being used with parameters.
* I failed to spot that the aws plugin is in-repo! Update that too.
* Remove code cleanup changes from this PR
* Wording and wrapping adjustment as requested.
* OSS: Add standard CIEPS request/response structs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* OSS: Add support for parsing TLS-related values
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* CreateOperation should only be implemented alongside ExistenceCheck
Closes#12329
Vault treats all POST or PUT HTTP requests equally - they default to
being treated as UpdateOperations, but, if a backend implements an
ExistenceCheck function, CreateOperations can be separated out when the
existence check returns false.
It follows, then, that if a CreateOperation handler is implemented
without an ExistenceCheck function, this is unreachable code - a coding
error. It's a fairly minor error in the grand scheme of things, but it
causes the generated OpenAPI spec to include x-vault-createSupported for
operations on which create can never actually be invoked - and promotes
muddled understanding of the create/update feature.
In this PR:
1) Implement a new test, which checks all builtin auth methods and
secrets engines can be successfully initialized. (This is important
to validate the next part.)
2) Expand upon the existing coding error checks built in to
framework.Backend, adding a check for this misuse of CreateOperation.
3) Fix up instances of improper CreateOperation within the Vault
repository - just two, transit and mock.
Note: At this point, the newly added test will **fail**.
There are improper uses of CreateOperation in all of the following:
vault-plugin-auth-cf
vault-plugin-auth-kerberos
vault-plugin-auth-kubernetes
vault-plugin-secrets-ad
vault-plugin-secrets-gcpkms
vault-plugin-secrets-kubernetes
vault-plugin-secrets-kv
vault-plugin-secrets-openldap
vault-plugin-secrets-terraform
each of which needs to be fixed and updated in go.mod here, before this
new check can be added.
* Add subtests
* Add in testing of KV v2, which otherwise doesn't get tested
This is a surprisingly complicated special case
* The database plugin needs special handling as well, and add in help invocations of the builtin backends too
* Fix extra package prefix
* Add changelog
* Update 6 out of 9 plugins to needed new versions
Note, this IS an upgrade despite the apparent version numbers going
down. (That's a consequence of slightly odd release management occurring
in the plugin repositories.)
* Update to deal with code changes since branch originally created
* Perform necessary update of vault-plugin-secrets-kubernetes so that CI checks on PR can run
* Fix another instance of incorrect CreateOperation, for a test-only endpoint
By being hidden behind a Go build constraint, it had evaded notice until
now.
* Add an opportunistic test of sys/internal/specs/openapi too
* OpenAPI: Separate ListOperation from ReadOperation
Historically, since Vault's ReadOperation and ListOperation both map to
the HTTP GET method, their representation in the generated OpenAPI has
been a bit confusing.
This was partially mitigated some time ago, by making the `list` query
parameter express whether it was required or optional - but only in
a way useful to human readers - the human had to know, for example, that
the schema of the response body would change depending on whether `list`
was selected.
Now that there is an effort underway to automatically generate API
clients from the OpenAPI spec, we have a need to fix this more
comprehensively. Fortunately, we do have a means to do so - since Vault
has opinionated treatment of trailing slashes, linked to operations
being list or not, we can use an added trailing slash on the URL path to
separate list operations in the OpenAPI spec.
This PR implements that, and then fixes an operation ID which becomes
duplicated, with this change applied.
See also hashicorp/vault-client-go#174, a bug which will be fixed by
this work.
* Set further DisplayAttrs in auth/github plugin
To mask out more duplicate read/list functionality, now being separately
generated to OpenAPI client libraries as a result of this change.
* Apply requested changes to operation IDs
I'm not totally convinced its worth the extra lines of code, but
equally, I don't have strong feelings about it, so I'll just make the
change.
* Adjust logic to prevent any possibility of generating OpenAPI paths with doubled final slashes
Even in the edge case of improper use of regex patterns and operations.
* changelog
* Fix TestSudoPaths to pass again... which snowballed a bit...
Once I looked hard at it, I found it was missing several sudo paths,
which led to additional bug fixing elsewhere.
I might need to pull some parts of this change out into a separate PR
for ease of review...
* Fix other tests
* More test fixing
* Undo scope creep - back away from fixing sudo paths not shown as such in OpenAPI, at least within this PR
Just add TODO comments for now.
* Fix `vault path-help` for selected paths with bad regexps
See the comment being added in `sdk/framework/path.go` for the
explanation of why this change is needed.
* Grammar fix and add changelog
* Also fix hardcoded expectations in a new test
* Add a couple more testcases, and some comments.
* Tweak spelling in comment
Vault API endpoints are defined using regexes in instances of the SDK's
framework.Path structure. However, OpenAPI does not use regexes, so a
translation is performed. It is technically possible that this
translation produces colliding OpenAPI paths from multiple
framework.Path structures. When this happens, there has formerly been no
diagnostic, and one result silently overwrites the other in a map.
As a result of this, several operations are currently accidentally
missing from the Vault OpenAPI, which is also the trigger for
https://github.com/hashicorp/vault-client-go/issues/180.
This PR adds a log message, to help catch such accidents so that they
can be fixed. Much of the PR is propagating a logger to the point where
it is needed, and adjusting tests for the API change.
With current Vault, this will result in the following being logged each
time a request is made which triggers OpenAPI generation:
```
[WARN] secrets.identity.identity_0cd35e4d: OpenAPI spec generation: multiple framework.Path instances generated the same path; last processed wins: path=/mfa/method
[WARN] secrets.identity.identity_0cd35e4d: OpenAPI spec generation: multiple framework.Path instances generated the same path; last processed wins: path=/mfa/method/totp
[WARN] secrets.identity.identity_0cd35e4d: OpenAPI spec generation: multiple framework.Path instances generated the same path; last processed wins: path=/mfa/method/okta
[WARN] secrets.identity.identity_0cd35e4d: OpenAPI spec generation: multiple framework.Path instances generated the same path; last processed wins: path=/mfa/method/duo
[WARN] secrets.identity.identity_0cd35e4d: OpenAPI spec generation: multiple framework.Path instances generated the same path; last processed wins: path=/mfa/method/pingid
```
I will submit a further PR to fix the issue - this one is just to add
the diagnostic.
