* NewCore tech debt refactoring
* addExtraCredentialBackends
* singletonMounts => mountTypeToken instead of 'token'
* NewCore tests support ent backend addition
* PR feedback
* reorder method calls
* mounthPath___ standardization
* Try to be more explicit about the min number of backends
* Include cluster listener
* explicit declaration of events before assignment
* Removed nil checking
* resolve conflicts
Co-authored-by: Peter Wilson <peter.wilson@hashicorp.com>
* Implement user lockout log (#23140)
* implement user lockout logger
* formatting
* make user lockout log interval configurable
* create func to get locked user count, and fix potential deadlock
* fix test
* fix test
* add changelog
* fix panic when unlocking unlocked user (#23611)
* adding testonly CI test job
* small instance for testonly tests
* feedback
* shopt
* disable glob expansion
* revert back to a large instance
* fix a mistake
When sending an event asynchronously, the original context used for
whatever generated the event (probably a synchronous, quick HTTP
context) is probably not what is wanted for sending the event, which
could face delays if a consumer is backed up.
I will admit myself to sometimes having "context blindness", where
I just take whatever context is incoming in a function and thread it
out to all calls. Normally this is the right thing to do when, say,
tying downstream API calls to an upstream HTTP timeout.
When making KV events, for example, we used the HTTP context for
`SendEvent()`, and this can cause the events to be dropped if they
aren't taken from the channel before the HTTP request finishes.
In retrospect, it was probably unnecessary to include a context in
the `SendEvent` interface.
We keep the context in place for backwards compability, but also in
case we want to use it for purposes other than timeouts and
cancellations in the future.
Co-authored-by: Christopher Swenson <christopher.swenson@hashicorp.com>
* Bump versions within transit managed key known issues
* Link in partials into 1.15.x upgrade release notes
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
* [QT-602] Run `proxy` and `agent` test scenarios (#23176)
Update our `proxy` and `agent` scenarios to support new variants and
perform baseline verification and their scenario specific verification.
We integrate these updated scenarios into the pipeline by adding them
to artifact samples.
We've also improved the reliability of the `autopilot` and `replication`
scenarios by refactoring our IP address gathering. Previously, we'd ask
vault for the primary IP address and use some Terraform logic to determine
followers. The leader IP address gathering script was also implicitly
responsible for ensuring that a found leader was within a given group of
hosts, and thus waiting for a given cluster to have a leader, and also for
doing some arithmetic and outputting `replication` specific output data.
We've broken these responsibilities into individual modules, improved their
error messages, and fixed various races and bugs, including:
* Fix a race between creating the file audit device and installing and starting
vault in the `replication` scenario.
* Fix how we determine our leader and follower IP addresses. We now query
vault instead of a prior implementation that inferred the followers and sometimes
did not allow all nodes to be an expected leader.
* Fix a bug where we'd always always fail on the first wrong condition
in the `vault_verify_performance_replication` module.
We also performed some maintenance tasks on Enos scenarios byupdating our
references from `oss` to `ce` to handle the naming and license changes. We
also enabled `shellcheck` linting for enos module scripts.
* Rename `oss` to `ce` for license and naming changes.
* Convert template enos scripts to scripts that take environment
variables.
* Add `shellcheck` linting for enos module scripts.
* Add additional `backend` and `seal` support to `proxy` and `agent`
scenarios.
* Update scenarios to include all baseline verification.
* Add `proxy` and `agent` scenarios to artifact samples.
* Remove IP address verification from the `vault_get_cluster_ips`
modules and implement a new `vault_wait_for_leader` module.
* Determine follower IP addresses by querying vault in the
`vault_get_cluster_ips` module.
* Move replication specific behavior out of the `vault_get_cluster_ips`
module and into it's own `replication_data` module.
* Extend initial version support for the `upgrade` and `autopilot`
scenarios.
We also discovered an issue with undo_logs that has been described in
the VAULT-20259. As such, we've disabled the undo_logs check until
it has been fixed.
* actions: fix actionlint error and linting logic (#23305)
Signed-off-by: Ryan Cragun <me@ryan.ec>
hc-github-team-secure-vault-core