This option did not respect whether or not versioning was enabled when
writing it out during generation.
This does mean that there is a breaking change for auth tokens, but as
it was a no-op anyways it's easy to fix and not something I want to /v2
about.
Do not allow PKI-KMS workers to have names updated via API
This would cause their public IDs to change, which we do not want.
Descriptions are also disallowed, since those come from the config file.
This also adds logic to allow upgrading from old KMS method to new, with
a test.
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>
This adds a new mechanism for worker authentication that uses the
third-party arbitration of the original KMS flow by leveraging
recently-added capabilities in nodeenrollment to support a registration
wrapper. This allows for workers to be registered to the system with
just a name and a matching wrapper, while at the same time allowing
these workers to be used for private Vault access and multi-hop as they
contain per-worker encryption keys and support rotation.
Nodes using this mode will generate and rotate credentials in-memory
(using another recently added nodeenrollment capability) so will have a
new set of keys on every startup. This has the side effect of ensuring
that there is never a conflict or re-use of these credentials.
Note that the normal test worker flow was using the now-deprecated KMS
method; there is still a test that uses this (explicitly) but all other
tests using test workers that did not specify a specific PKI flow now
actually use this mechanism. This means there is fairly decent test
coverage in a general sense, plus the specific tests updated/added for
this feature.
This also adds a new KMS type that can be used to have
distinct KMSes for upstream authentication vs. accepting from
downstream.
The `boundary connect` subcommands attempt to parse the credentials to
use for brokering. This allows the subcommands to insert the credentials
automatically into the process called by the subcommand, i.e. `ssh` or
`psql`. There is some fallback logic to try a best attempt at parsing
the credential in cases where a credential type has not be set on the
credential source.
The bug was introduced with the recent change to the vault credential
library subtype being renamed from `vault` to `vault-generic`. This
fallback logic would only run if the credential source type was "vault"
or "static", so if the vault credential library was created without
specifying a credential-type, the credential would not be parsed and
automatically passed to the sub-process.
This fix removes the additional check on the credential source's type,
instead it will attempt to parse the credential, relying just on the
structure of the credential.
This also fixes a similar bug in the table output of secrets when using
`boundary connect` without a subcommand. The parsing of the credentials
for display in the table was only running for `vault` or `static`.
Blame: db42eafd7a
When using the json output of the cli (`-format=json`), a successful
call to the controller API would place the HTTP status code in the JSON
as `status_code`. However, if there was an error from the API the status
code would be placed in the JSON as `status`. In order to be consistent,
this adds a `status_code` field to the error response case. For
backwards compatibility it still populates `status` in the error case.
This inconsistency was missed partially due to a bug in the CLI tests.
The assertion on status code was not valid and would always be
successful. Thus this also fixes the assertions and tests.
* Fix target port handling
This fixes two issues that compounded on each other (see the Changelog
update for more information):
* The verification logic for hosts was not correct for update operations
(in multiple ways) which meant that a host could be updated after
creation to have a port. Targets had a previously fixed bug where they
did not require a default port, which meant that ports could be used
from hosts
* A recent (unreleased) change had prioritized any port coming from the
host over the default port, which would mean there was no way if a
host had a port specified to use it in multiple targets.
This fixes the update verification logic, and strikes a middle ground
between breaking things and not by allowing existing addresses with
ports to be used with targets but ignoring that port, instead requiring
targets to have default port set at authorize time (currently there is
backwards compat that does not require this due to the original optional
port bug).
* Update CHANGELOG.md
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
The wh_upsert_credential_group function was incorrectly attempting to
update the session connection fact table. There are a couple problems
with this:
1. At the time that this runs, there would be no session connection facts
for this session.
2. This function is meant to update the session fact table, there is a
separate function that associates the credential group with the
session connection facts.
This also fixes another bug that was causing expired rows of the
credential dimension to be included in the group membership. And finally
it fixes a typo in the function name.
* add custom ResponseWriter struct to inject custom response headers based on status code
* docs
* upgrade listenerutil
* fix config tests
* replace all instances of "data:*" with "data:" to reflect changes to listenerutil
* swapping strings.HasPrefix in favor of mux.Handler for ui request matching
* set ui path as const
* add custom response headers to changelog
* fix(worker): Verify contents of loaded session (#2629)
* fix(worker): Verify contents of loaded session
Previously, it was possible for an empty private key to be used
when the session had no user or project associated with it.
The new checks guarantee that we will fail gracefully in these
cases.
* Check against len instead of nil
* Add CHANGELOG
* fix(session): Always invoke all parts of session cancel trigger
The session cancelation trigger would not set the key_id to null
appropriately if another one of the fields on the session was
already null, since that case statement would be matched first.
The new structure matches all statements, in case any of them have
special logic (such as in the project case).
Add initial templating support to Vault credential libraries
This adds support for templating various account and user values into
Vault dynamic credential library POST bodies and GET/POST paths.
It also unifies how parameters are used in grants, with backwards
compatibility.
* Randomize order of worker output. This uses the standard
rand.Shuffle() call; cribbed from
https://pkg.go.dev/math/rand#example-Shuffle
* Have some error/eventing in the worker status path use the base
context instead of the status-call-specific context to allow eventing
after a timeout event
The schema changes introduced in 0.10.2 introduced a bug where an org
could not be deleted if there was a session for an org scoped user. It
would result in an error like:
scope.(Service).deleteFromRepo: unable to delete scope: \
iam.(Repository).DeleteScope: failed for o_VkNy46KwfS: \
iam.(Repository).delete: db.DoTx: iam.(Repository).delete: \
db.Delete: insert or update on table "session" violates foreign key constraint "target_fkey": integrity violation: error #1003
A worker around would be to first delete all projects in the org, then
finally delete the org.
This fix adds a regression test to the sqltests and updates several
constraints on the session table to be deferrable. Since the org delete
is a single transaction, this allows all of the necessary resources to
be deleted before attempting to enforce these constrains.
See: https://www.postgresql.org/docs/current/sql-set-constraints.html
Blame: 3a28ab614
* feat(workers): Add ability to read and reinitialize cert authority (#2312)
* feat(workers): Return Release Version on worker list and read (#2377)
* feat(cli): Read and reinitialize worker certificate authority (#2387)