This removes the Cartesian product in the DB for GrantsForUser in favor
of returning the actual grant scope information and dealing with it in
application code.
(cherry picked from commit 913cd536823d73994acc4f4d833208c1cc05f91b)
* Add ListResolvableAliases to the user service
There are a few non common ways this method uses our ACL
and grant system. A user is able to list resolvable
aliases for another user if they are granted permission
to do so. That means we had to load the grants for
the user being listed for and not the requester when
determining if an alias is able to resolve to a destination
for which the requested user has permission.
Similarly, the grant hash used for the list pagination
is required to be that of the user being listed and not
the requester.
This switches the implementation of an ActionSet from a slice to a map
to ensure the elements in an ActionSet are unique. This allows for other
packages to perform set operations such as a union or difference without
needing to account for duplicates.
* Adding explicit MPL license for sub-package.
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Adding explicit MPL license for sub-package
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at www.hashicorp.com/licensing-faq, and details of the license at www.hashicorp.com/bsl.
* Update copyright file headers to BUS-1.1
* Rerun make gen
This will pick up the last of the license changes
* Revert "Rerun make gen"
This reverts commit dbe0968bffd92745d8663c6940debae098395a6b.
* Remove copywrite from generation script
The current version of copywrite is not sophisticated enough
to only apply the copywrite changes to certain subdirectories,
so to avoid accidentally relicensing our api and sdk modules,
we will stop running the copywrite script until such time
that it can do the right thing.
* License protobuf API as MPL
The protobuf API files are used to generate the SDK,
since we want the SDK to be MPL, the protobuf files
must also be MPL. This extends to all protobuf files
whose sources end up in the SDK directory, including:
- internal/proto/controller/api
- internal/proto/controller/custom_options
- internal/proto/plugin
It also includes the generated service directory in
internal/gen/controller/api/services, since they are
generated from the protobuf sources used for the SDK.
* Change website license file name
This makes the naming scheme consistent with the rest
of the repository.
* Add note on licensing to README
* Set copywrite license to BUSL
* Revert "Add note on licensing to README"
This reverts commit 4d865a91a7a4f11605f0dc4609355d7e3c3cfffe.
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
This allows specifying multiple IDs in grants via an `ids` field, which
will eventually become the normal way to specify IDs. Internally, each
grant with multiple IDs turns into multiple ACL grants each with a
single ID; to make this distinction clearer and allow for better
separation of concerns an AclGrant type has been introduced, so really
multiple IDs in a Grant turn into multiple AclGrants.
The nice thing about doing it this way is that it becomes purely a
parsing concern; no actual validation logic has changed.
For backwards compatibility with grants already stored in roles, we do
not error out if `id` is specified. However, eventually we will simply
not support grants with `id` coming via the API; they will fail API
validation, such that new grants will require the use of the updated
`ids` field.
A follow-on PR will plumb this through the service handlers/API/CLI, but
I decided to do it in separate chunks to make reviewing easier, given
that they are easily separable into the internal and external aspects of
the change.
* Add CLI/API checks around using ID in grants (#3264)
* Plumb through some contexts to remove a lot of deprecated errors (#3268)
`action.List` is a collection action, that is, it is not part of the set
of actions that can be executed against a single instance of any given
resource.
As part of the `ListPermissions` call, `idActions` is expected, that is,
all the actions that can be executed against a resource instance.
`action.List` will never be part of this. This commit updates the tests
to reflect this fact.
This makes two changes:
1. ListPermissions assumed every grant string had a type field, which
does not match all grant formats. It now infers type from ID for
formats which do not specify type.
2. Allow ID-only grant strings to be valid so long as the type specified
matches the type of the specified ID.
This adds several relationships into the resource package that are then
made use of to improve the grant validation that runs during Parse. By
understanding mappings between ID and resource type the validation
checks can far better align with actual allowed grant formats so we can
find several common misunderstandings before they simply result in an
authorization failure.
In the future some of these functions could be used in the logic in the
actual ACL checks but it's not currently necessary and I don't want to
lump that change in with this.
Note that the tests have not meaningfully changed, but they _have_ had
to be updated because the stricter validation is actually catching
issues.
* testing(perms): Add Parse fuzz test
I ran this for a few minutes and it didn't discover anything catastrophic.
* Add roundtrip tests
* Fix invalid unicode parsing, empty output fields
* Do the unicode conversion once on input
* Remove incorrect fix for empty output fields
* Allow empty output_fields
This is the same behavior as output_fields=,
* Add tests back, make JSON behaviour consistent
* Rework the output fields mechanism to fix some bugs such as properly handling no fields
* Change signature of Fields
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
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.
* 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)
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>
This is a bit more than simply adding the action; we had some
checks to ensure that list/create could only happen/not happen
in some cases and those had to be modified to account for
subactions.
Current behavior is that you need list grant on the parent scope when
recursively listing, and this is sufficient. This is good for
administrative workflows but can be unintuitive for resources that only
exist at a project level. This change allows permissions on the child
scope to also be taken into account, so that you can start a recursive
list from a parent scope without direct list support on that scope but
still get back child scopes for which list access is granted.
This also fixes a bug where visibility of a scope for recursive listing
would be based on whether the user had list resources for roles within
that scope instead of for the resource type in question.
* Adding grants related methods to Roles.
* Adding grants back after the merge of Principals.
* Adding tests for Grant related custom methods.
* Improving api handler methods.
* Fixing tests and sdk field.
* Adding todos for adding principals and grants to List and Update Role responses.
* Fix up Set* tests and fix SetPrincipals bug.
* Making AddPrincipals and RemovePrincipals similar to the tests for AddGrants and RemoveGrants.
* Add JSON grants to output (#187)
I also changed canonical_grants to grants_canonical and used
grants_json. I believe that when members are simply different formats of
other members this is the preferred way to have it in the API. Let me
know if you disagree and we can dig in more.
* Regenerate the API role resource.
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
This removes the ability for a grant string to switch projects, in
accordance with our updated design. It mostly removes code, with a few
test fixes, and also adds one additional check (and test) to ensure a
grant errors rather than do-nothing succeeds if both id and type are
empty.
This adds parsing and validation for grant strings along with the ability to create canonical JSON and text strings from a grant.
It also adds an ACL implementation, allowing a collection of grant strings to then be checked against a resource/action tuple and indicate if it's allowed.
Note that only specific sets of provided data in grant strings is allowed. This vastly simplifies logic.
Test coverage is 100%.
A future update will consolidate and migrate types between this and IAM but I didn't want to mix that in with this.
Jeff Mitchell
Todd
Michael Milton
Damian Debkowski
Hugo
hashicorp-copywrite[bot]andJohan Brandhorst-Satzkorn
Louis Ruch
Hugo
Irena Rindos
Jim
Todd KnightandJeff Mitchell
