When generating permissions from the grants, if a single grant was
limited to the set of "self" actions, the permission would be marked as
only self, even if additional grants were given for non-self actions.
This would result in the generated permissions being more limiting then
they should be based on the grants. This only impacts the sessions list
endpoint. It would result in users that have been granted access to list
other user's sessions to be unable to see these results in the list
results.
If the database url is updated on Boundary's config and then a SIGHUP
triggered, we now connect to the new database, ensure it's OK to use
and use that one going forwards instead.
This allows a controller to be deployed in a more dynamic infrastructure
where, for example, database credentials could change, without having
to restart the controller.
This operation is done atomically to prevent errors and inconsistency.
A timeout is present so that if the object is swapped after the
existing one has been looked up it isn't immediately invalidated.
The timeout is a maximum; a ticker once a second that looks at
stats to determine how many database connections are still in use
and then closes the driver as soon as none are in use.
If the database url is updated on Boundary's config and then a SIGHUP
triggered, we now connect to the new database, ensure it's OK to use
and use that one going forwards instead.
This allows a controller to be deployed in a more dynamic infrastructure
where, for example, database credentials could change, without having
to restart the controller. In this case only a database url config
change and a SIGHUP signal to all controllers would be required.
This uses an atomic.Pointer to store wrapped DB objects. This allows
atomically swapping to the new object. A timeout is introduced so that
if the object is swapped after the existing one has been looked up it
isn't immediately invalidated. The timeout is a maximum; a ticker once a
second that looks at stats to determine how many database connections
are still in use and then closes the driver as soon as none are in use.
This could be done with mutexes to avoid checking stats in a loop, but
that carries its own risk: if a write lock is attempted to be acquired
while a query is holding a read lock, the write lock will block, and any
subsequent read locks will also block since write locks take priority.
As a result, if a query is long-running or timing out, all other queries
in the system will become blocked. Our default user request timeout is
90 seconds and some jobs have no timeout at all, so this is not a purely
theoretical concern, even if it's unlikely.
Refs: #2435
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
This commit extracts 3 separate pieces of functionality into their own
function/method:
- Extracts the database opening with the intention to have a function
that performs all that functionality but returns the created database
object rather than setting it to the Server structure.
- Extracts database validation logic, to provide a common code path for
upcoming functionality.
- Expose schema manager on the Command struct as well as providing
common functions to acquire shared lock/close.
This commit introduces closing the Schema Manager's underlying driver
connection. We were only releasing the shared lock but not actually
cleaning up the db connection and relied on the fact that the process
would exit to do that for us.
In cases where the server was started with both a controller and worker
stanza, the reload of the config was not properly setting the initial
upstream value on the new config. In this case the value is derived from
other config values and not necessarily set directly.
This now properly initializes the new config so that initial upstream is
set in the same manner as the first load.
Blame: 5d0cdf680f
* 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)
Improve response time for list requests for targets and sessions. This
refactors the behavior between the target and session services and how
they interact with the domain layer. Now the service is able to evaluate
the set of permissions from the requesting user's grants, use these
permissions when constructing the corresponding repository, and retrieve
the list of the resource the user is authorized to list in a single
query.
This reduces the round trips to the database and greatly reduces the
amount of data received from the database.
This impacts commands (in particular when `-recursive` is used):
boundary targets list
boundary sessions list
And the corresponding API endpoints of:
GET /v1/targets
GET /v1/sessions
There is no change to the data returned.
See:
68568828e6bf263fbd7d
Using the new Permissions object, we can build a list of the level of
access a user should have based on the grants they've been given,
meaining we don't need to fetch all resources from the database to then
remove the ones the user shouldn't be able to see.
This commit also removes some unused options in `ListTargets`
for the sake of simplicity.
This unexported method was only used by a single test, and was taking
advantage of its implmentation to populate Connections rather than
Sessions. This repository should only interact with Sessions, since
there is a separate repository for Connections.
This adds a context to the session.RepositoryFactory, allowing
errors.NewDeprecated to be replaced with errors.New. It also removes the
common.SessionRepoFactory, instead packages just directly import from
the session package.
This builds on previous performance improvements to the list behavior by
reducing the number of queries against the database and the amount of
data transfered in order to retrieve a list of sessions. Previously, a
query was performed to retrieve a tuple of `(session_id, scope_id,
user_id)` for the requested scope, including all child scopes if the
request was recursive. These tuples were evaluated against the
requesting user's grants to identify the sessions that they were
authorized to list. In the case of clusters with a large number of
sessions, this would result in a large amount of data needing to be
transfered for sessions that would not be used. Then a second query
would be used to retrieve the full session information for the session
ids that were authorized.
This changes the list behavior to evaluate a set of permissions from
the requesting user's grants, use these permissions when constructing a
session repository, and retrieve the list of sessions the user is
authorized to list in a signle query.
Ref:
d74103482932070678dc
The session repository can now be passed an optional set of permissions.
The permissions are used to restrict results from the repository.
Currently this only impacts the List method. This enabled the sessions
service to use a single query to retrieve sessions and replaces the
previous behavior where the session service would first request all
sessions for a given set of scopes, evaluate the permissions, and then
request sessions based on a set of session ids.
Disabling the auth was resulting in some unrealistic tests setup and
expectations. It also makes it difficult to refactor any behavior in the
authn/authz flow since this option can bypass most of it.
Disabling the auth was resulting in some unrealistic tests setup and
expectations. It also makes it difficult to refactor any behavior in the
authn/authz flow since this option can bypass most of it.
* feat(workers): added latencies histogram for server side multihop workers
* refactor(daemon): combine common grpc metric functions into daemon/internal/metric
Co-authored-by: Todd <github@quaddi.com>
Irena Rindos
Louis Ruch
Jeff Mitchell
Dharini Jeeva
Damian Debkowski
Yoko Hyakuna
Timothy Messier
Hugo
Todd
Johan Brandhorst-Satzkorn
HaotianandTodd