This adds an action to the API that allows pulling out an activation
token that can be given to a worker in its config (directly or via env
or file). The worker can pass this along with its normal request in
place of its normal nonce and the server will automatically accept it.
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>
* Have hclog payloads use `json` tags
Previously a global setting for the `structs` lib was causing the `json`
tag to be used, but this could have side effects from other packages, or
could be affected by other packages' behavior. This behavior was removed
earlier but it means this format call no longer uses `json` tags; this
behavior reverts it.
It also normalizes using mapstructure in a few other places.
* Update some tests
* Fix incorrect op const
* Fix more tests
* refactor (events): tell filter to use json tags (fix related tests)
Explicitly tell the filter to use the "json" tags so we don't have to
re-tag everything with a mapstructure tag via bexpr.WithTagName("json")
Update docs
Co-authored-by: Jim <jlambert@hashicorp.com>
This feature allows the user to set the `tags` field to a string
that points to either an environment variable or file.
We then dynamically pull out the value and parse it into the config.
This can also be done at the keys level, where you set your keys
directly in Boundary's config file, but point the values to env/file.
This stores worker connection nonces within the database to ensure
uniqueness of connections. Prior the connection required any attacker to
be able to decrypt the incoming encrypted authentication message in
order to replay (and if the attacker has access to the KMS you have
bigger problems), but with this change even if an attacker does have
access to the KMS key, they cannot reuse the same message. (If they're
able to encrypt against the KMS key, they can still act as a worker with
a new message, so this only really helps if they only have decryption
capabilities.)
Because of listing visibility, if no actions are assigned to a user for
an individual resource, it's excluded from the list. This is fine and
good. However, when we made a change in 0.2.0 to restrict the
information returned from listing for the anonymous user for scopes and
auth methods, it exposed the fact that because of the way this
visibility works we had to add `read` to scopes by default -- thereby
rather defeating the purpose of restricting what goes back to `u_anon`
requests.
The purpose of "no-op" is to never be used for real actions within the
API, but as something that can be granted to specifically enable
visibility for the targeted user. This makes the controls over list
visibility much more granular.
I'm not sure why it was doing it the other way with assuming the string
being built would always have a space at the end, but, this way is
easier to understand and fixes a bug where there wasn't a space being
left between some fields.
* Add -filter to CLI listing.
This doesn't include docs/Changelog yet, that will come shortly.
* Add changelog
* Add website docs and fix a curl output bug
* Sessions support for read:self and cancel:self permissions. This is automatic with fallback; no API change is needed.
* Strips out values from listing if only self actions are allowed on the resource and the user ID is different. This prevents a default ACL of id=*;type=session;actions=read:self,cancel:self from causing all values to be visible when listing.
* Adds an unprivileged user to development/testing instances. This user has only default permissions plus the ability to authorize sessions in the default target.
stephan242
Irena Rindos
Jeff Mitchell
Yoko Hyakuna
Loann Le
Louis Ruch
Jeff Malnick
PPacent
Hugo Vieira
Todd
Michael Gaffney
Carlos Alcaide Corvo
John Reese
Bryce Kalow