Update changelog (#1362)
This commit is contained in:
1 parent
13a65052b4
commit
89dfbbe41e
1 file changed
+30
-1
+30
-1
@@ -8,9 +8,38 @@ Canonical reference for changes, improvements, and bugfixes for Boundary.
|
||||
|
||||
### New and Improved
|
||||
|
||||
* Credential Stores: This release introduces Credential Stores, with the first
|
||||
implementation targeting Vault. A credential store can be created that accepts
|
||||
a Vault periodic token (which it will keep refreshed) and connection
|
||||
information allowing it to make requests to Vault.
|
||||
* Credential Libraries: This release introduces Credential Libraries, with the
|
||||
first implementation targeting Vault. Credential libraries describe how to
|
||||
make a request to fetch a credential from the credential store. The first
|
||||
credential library is the `generic` type that takes in a user-defined request
|
||||
body to send to Vault and thus can work for any type of Vault secrets engine.
|
||||
When a credential library is used to fetch a credential, if the credential
|
||||
contains a lease, Boundary will keep the credential refreshed, and revoke the
|
||||
credential when the session that requested it is finished.
|
||||
* Credential Brokering: Credential libraries can be attached to targets; when a
|
||||
session is authorized against that target, a credential will be fetched from
|
||||
the library that is then relayed to the client. The client can then use this
|
||||
information to make a connection, allowing them to gain the benefit of dynamic
|
||||
credential generation from Vault, but without needing their own Vault
|
||||
login/token (see NOTE below).
|
||||
* `boundary connect` Credential Brokering Integration: Additionally, we have
|
||||
started integration into the `boundary connect` helpers, starting in this
|
||||
release with the Postgres helper; if the credential contains a
|
||||
username/password and `boundary connect postgres` is the helper being used,
|
||||
the command will automatically pass the credentials to the `psql` process.
|
||||
* The worker will now close any existing proxy connections it is handling when
|
||||
it cannot make a status request to the worker. The timeout for this behavior
|
||||
is 15 seconds.
|
||||
is currenly 15 seconds.
|
||||
|
||||
NOTE: When using credential brokering, remember that if the user can connect
|
||||
directly to the end resource, they can use the brokered username and password
|
||||
via that direct connection to skip Boundary. This isn't any different from
|
||||
normal Boundary behavior (if a user can directly connect, they can bypass
|
||||
Boundary) but it's worth repeating.
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
|
||||
Reference in new issue
Block a user