Reading a token from the keyring can sometimes fail for reasons
other than the token not being present in the keyring. This PR
introduces a new error used to indicate that the token requested
could not be found in the keyring and propagates errors from the
keyring up to the caller, so that the caller can act on them.
Additionally, this fixes a bug in the client cache where it would
incorrectly assume that a token had been removed from the
keyring, when in fact there was an error reading from the keyring.
TestRotationTicking would previously wait for 5 rotations, which is
pretty slow considering each rotation takes 20 seconds. Reduce
the number to 3, and use require instead of assert to remove
noise during flaky test runs.
This doesn't fix the flakiness of this test, but it should reduce the log spam.
Don't error in ReleaseGate if the context used for the original
event has been cancelled. Any error in ReleaseGate causes the
controller to terminate its startup. If a user was trying to send
a request to the Boundary controller as it started up, the context
tied to the request would be reused to attempt logging the
observation associated with the request after the logging gate
was released. This would always fail, as the context associated
with the request was canceled.
We now use a new context timeout for events logged after the release
gate is released, if the original context was canceled.
* Update release dir owner group
The old group only contains a service account. I updated it to the self managed release engineering group instead.
* Remove release engineering as code owners
Actually lets just remove this group, as per their justification in #4057
Previously, if one of these tests failed to start their servers before
the timeout, there was a risk that the goroutine started to run
the server would invoke t.Errorf after the test itself had concluded.
Replace t.Errorf with fmt.Printf to avoid the panic, and include
the test name for debugging.
* internal/handlers/managed_groups: ensure membership lookup is unlimited
Previously, we would only show the first 10,000 members in the group,
giving the impression that a complete list was performed. Now we
list all members.
* internal/handlers/accounts: ensure group lookup is unlimited
Previously, we would only show the first 10,000 managed group
memberships. Now we list all group memberships of an account.
Previously, we would list the managed groups with an implied
filter of db.DefaultLimit (10,000), which would incorrectly remove
a user from managed group memberships if there were more
than 10,000 managed groups in an auth method. Explicitly
set the list limit to unlimited to ensure all managed groups are
updated appropriately.
* docs/client-agent: clarify use of override_upstream_dns_servers
The override_upstream_dns_servers option is recommended whenever
a user needs to override the DNS servers discovered from the system.
However, if a user supplies a DNS server that is only useable while
connected to a specific network, it will break the internet in
cases where it is not able to resolve these DNS servers.
Encourage users to supply both the VPN servers and the default
DNS servers.
* Update website/content/docs/api-clients/client-agent.mdx
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
* Update website/content/docs/api-clients/client-agent.mdx
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
---------
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
* docs/client-agent: clarify configuration reload on MacOS
The previous configuration was known to confuse at least one reader.
It's easy to just copy the first command you see and run it, so
make that the non-destructive reload command.
* docs/client-agent: correct log level config example
* Update website/content/docs/api-clients/client-agent.mdx
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
---------
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
* docs/client-agent: indent PAN docs correctly
Identifying the primary network interface is a sub-heading under the
PAN troubleshooting section.
* docs/transparent-sessions: add known issue around containers/VMs
VMs/containers that do not have access to the local network cannot
use aliases through transparent sessions.
* Add semgrep rules
Instrument our security scanner with the ability to use custom semgrep
rules. This is inspired by the HVS teams use of semgrep.
* semgrep: add rule to detect string interpolation in WithInfoMsg
The event.WithInfoMsg function expects a set of key value tuples,
but it can easily be misunderstood to accept string interpolation
arguments. This check will error if any string interpolation verbs are
used in calls to event.WithInfoMsg
Propagate the downstream worker timeout into the
downstream receiver and downstream ticker
so we have a configurable consistent timeout
value to use for worker to worker interactions.
Also change the atomic.Pointer to an atomic.Int64
for consistency with other values.
* internal/session: update variable name in test
This was missed in #5071
* internal/tests/cluster: skip failing tests
These tests will need to be fixed or removed. It is not
clear why they are failing, but they are always failing.
* Makefile: try upgrading golangci-lint
* internal/host/plugin: fix flaky test
Hosts contain IP addresses in string form, whose
order is not defined.
The API automatically paginates to the end of a pagination,
and would take into account any items updated and subsequently
removed since the last pagination. It now also removes any items
removed during the current pagination.
* 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>
The client agent serves on "localhost:9300" by default. It appears
on some systems this resolves to ::1:9300 and on some systems
127.0.0.1:9300. We should use the same address on the client
as the server to avoid any incompatibilities between systems.
* 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>
* internal/gen: better API docs
Add various pieces of metadata that can be used by the API docs renderer.
Improve the service labels by specifying explicit tags.
Specify error responses. Specify version at generation time.
* internal/gen: add better errors
The default error entry is now used to cover all errors, as
adding a new error for every possible status code was a bit much.
This also properly includes the real error type now!
* Add various pieces of metadata that can be used by the API docs renderer. Improve the service labels by specifying explicit tags.
* make auth method API docs
* make API docs better
* make auth methods API docs nicer
* internal/gen: better attribute examples
Replace Output Only comments with a field behavior annotation in accounts.
Mark some fields as required.
Add elaborate description for attributes.
* Make API docs better
* Make API docs better
* Make API docs better
* internal/proto: regenerate files
* internal/proto: finish off account service
* Make API docs better
* internal/proto: add better API docs for aliases
* Tidy up service descriptions
* Added description for Boundary controller API doc
* internal/gen: add better API intro
Copy parts of the API docs into the description
* sdk: add openapi dependency
* internal/gen: move global API doc to separate file
* internal/gen: remove required annotations
Unfortunately, while these help with the creating of resources, they still
appear required in contexts where they are not, such as when
updating a resource.
* Review comments
---------
Co-authored-by: jigar-hashicorp <jigar.shah@hashicorp.com>
Co-authored-by: Isaac Christian (he/him) <112639904+isaacchristian@users.noreply.github.com>
* handlers/targets: always return pagination parameters in list
* handlers/authmethods: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/accounts: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/authtokens: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentiallibraries: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentials: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/credentialstores: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/groups: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/host_catalogs: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/host_sets: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/hosts: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/managed_groups: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/roles: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/scopes: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/sessions: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
* handlers/users: test for pagination parameters
Note that this already always returned the pagination parameters,
but now we have a test that it does so.
Use the existing auth token account view for listing
instead of a custom query. Testing shows that the
performance difference is negligible, and this is simpler.
Ensure the new create_time and update_time columns
are marked as not null after populating the data.
Also ensure that the data is populated safely with an
updated query pattern inspired by the auth method
pattern.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids this issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
The previous sort would run the risk of missing items which
collide on update or create times because of the compound
comparison using strictly less than for both the timestamp
and the public_id. Sorting both descending avoids thi issue.
