This add the generated code and additional configuration to support
sending the ssh target subtype to the api via the sdk or cli.
The cli now supports an additional subcommand for the ssh target
subtype:
boundary targets create ssh
boundary targets update ssh
* feat(credentials): Refactor credential purposes
* Application credentials have been refactored to Brokered credentials
* Egress credentials have been refactored to Injected Application
credentials
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* Add support for ssh_private_key credential type in Vault libraries
* Add support for ssh_private_key credential type
* Support jsonpointer for Vault library mapping overrides
* Have fallback eventing use json format
The server will initialize a logger via InitFallbackLogger(...)
after setting up the server's logging (and honoring the related
cmd flags). This fallback logger will be used if when no eventer
is initialized.
If no fallback logger is initialized, then a event.defaultLogger() will
be used if no eventer is defined.
Co-authored-by: Jim <jlambert@hashicorp.com>
Right now there is a bit of a race condition in that a status call that
indirectly tells the controller that a worker is ready to accept
sessions can have its response unable to be processed in time for an
actual session to come in from a client. It's very unlikely but
technically there.
This changes where we check if we have ever successfully authenticated
from the function called by the ticker to the ticker itself, allowing us
to reset the timer to a very short time if we have not yet
authenticated. We already have the initial timer set to 0 for "as soon
as possible" behavior, but if that initial status failed we'd wait for
the normal interval. Now we will instead continue with the "as soon as
possible" behavior, and reduce the very unlikely race condition to
extremely unlikely.
(There are more permanent fixes but those are bigger and can come
later.)
This adds two new config options for the `database` stanza:
- `max_idle_connections`
- `max_idle_time`
These correspond to settings for the underlying `sql.DB` instance. They
can be used to have finer control over the controller's database
connection pool. For example this can be used to mitigate the high
connection overhead when connecting to postgres by setting a high
`max_idle_connections` and either setting `max_idle_time` to zero or to
a high duration.
Alternatively, if using a connection pool like pgpool-II or pgbouncer,
`max_idle_connections` can be set to 0.
See:
https://pkg.go.dev/database/sql#DB.SetMaxIdleConnshttps://pkg.go.dev/database/sql#DB.SetConnMaxIdleTimehttps://www.pgpool.net/mediawiki/index.php/Main_Pagehttps://www.pgbouncer.org/
Irena Rindos
irenarindos
Jeff Mitchell
Damian Debkowski
Louis Ruch
Timothy Messier
Jim
Cameron Perera
Mark Lewis
Michele Degges
Robin Beck
Haotian
Loann LeandRobin Beck
Michael Gaffney
Johan Brandhorst-Satzkorn
Todd
Danielle Miu
Jeff Malnick
Carlos Alcaide Corvo