This adds grant_scope_ids in the output of role listing. The lookup for grant scope IDs was changed to allow taking in a set of roles instead of just a single role, and the results are collated afterwards.
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* api: remove deprecated grant_scope_id field
The grant_scope_id field was deprecated in 0.15.0, so we can remove
it for 0.17.0.
* Fix tests
* Fix more tests
* Remove an option and some related code that stuck around
* Fix bats tests
---------
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* Allow names and descriptions to contain newlines and other whitespace
* separate validate name from validate description
* update changelog
---------
Co-authored-by: Danielle Miu <29378233+DanielleMiu@users.noreply.github.com>
* internal/cmd/wrapper: add deprecation wrapper
The deprecation wrapper can be used to display a warning to callers
when a command is deprecated.
* all: rename daemon to cache
Rename the boundary daemon command to boundary cache. This
avoids confusion with future client/daemons.
* changes daemon to cache in nav
---------
Co-authored-by: Robin Beck <stellarsquall@protonmail.ch>
The cluster listener supports a `max_request_duration` option, and
defaults to 90 seconds. However, this configuration was not being use
when processing grpc requests from the listener. This meant that
requests from worker to controller could hang indefinitely and
contributed to the recently fixed issue with database connections being
stuck in `idle in transaction`.
This commit adds a grpc interceptor that ensures each request has a
deadline set to the max request duration for the listener.
Refs: 29cd7bc9d6
* fix: Proxy closing listener with 0 connections left
A bug was introduced in `0.15.0` where sessions with max connection counts were closed when the connections left hit 0. This issue was highlighted by a user: https://github.com/hashicorp/boundary/issues/4364. What was happening was when we have zero connections left the proxy code was closing the listener which closed its connections
To fix this:
- `boundary connect -target-id=xx -host-id=xx` command with no connections left will now wait for all connections to be closed and before exiting the session just like it did in `0.14.3`
- As soon as there are no more connections left, the listener will close to stop accepting new connections
- Fix issue where the websocket connection was throwing closing errors during the session teardown.
* Decrease number of flags shown for daemon/search
* Update changelog
---------
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* Update changelog with UI notes
* Update CHANGELOG.md
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* Update CHANGELOG.md
Moved changes description to UI in to the `policies` section
* fix indentation
* Update CHANGELOG.md
* correct left indentation
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* Add generic read/update/delete commands
This adds three generic commands that use the resource prefix to
determine the subcommand to run and pass through args over to that
subcommand. Since this occurs very early on and to avoid loading
essentially every internal resource package, I moved subtype definitions
to globals.
This replaces #3967
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* De-duplicate Subtype code (#4031)
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
* Add generic read/update/delete commands
This adds three generic commands that use the resource prefix to
determine the subcommand to run and pass through args over to that
subcommand. Since this occurs very early on and to avoid loading
essentially every internal resource package, I moved subtype definitions
to globals.
* Update main.go
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* Update changelog and remove another deprecated command
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* fix: monitorUpstreamConnectionState CPU consumption
`monitorUpstreamConnectionState()` is a goroutine that listens for GRPC client connection changes using GRPC's `WaitForStateChange` method. `monitorUpstreamConnectionState()` was consuming the a lot of CPU. It was continuously running and not actually waiting for state changes. The `state` for `monitorUpstreamConnectionState()` was not getting correctly updated which caused the loop to continuously run instead of waiting for new state changes.
Update GRPC `WaitForStateChange` method to use the same `state` that gets updated.
When the boundary client establishes a connection to the websocket used
to communicate with a worker, it was configured with a max websocket
message size of 32KiB. This was the default behavior for v1.8.7 of
nhooyr/websocket. However, there are cases where the worker can send
messages to the client that are larger than 32KiB. When this happens the
client returns an error and terminates the connection.
Notably this seems to only currently impact sessions made to SSH
Targets, although it could theoretically impact any target type
depending on the details of how the worker performs the writing of the
messages. The issue can be reproduced by attempting to scp a large
enough file from an SSH Target to the client. In this case the
connection gets terminated and results in a partial transfer of the
file.
This message size limit appears to be unnecessary, and the default
behavior is changing in v1.8.8 of nhooyr/websocket to make the message
size unlimited. Since this version is not yet released, this commit
switches the dependency to a fork with a version that is v1.8.7 plus the
patch to disable the limit. Once v1.8.8 is release this dependency can
be set back.
See:
https://github.com/nhooyr/websocket/pull/254https://github.com/nhooyr/websocket/pull/256