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.
* 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>
* 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)
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.
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.
This also affected credential libraries and managed groups. It seems
that any end-to-end tests of these grants currently had them included in
wildcards instead of individually, but these types were never added to
the valid list for resources. Additionally, credential store wasn't
added as a valid top level type for pinning purposes.
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.
* Remove list:self from main
As per futher discussions, we won't be supporting this, in favor of
simply read:self and cancel:self (since listing now already filters out
items on which you have no permissions).
This doesn't remove list:self entirely from the code base as much of
that will simply be converted to read:self and cancel:self -- that will
be in a later PR. However, with this removed if we want to release we
won't expose an API publicly that isn't going to stick around.
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
Timothy Messier
hashicorp-copywrite[bot]andJohan Brandhorst-Satzkorn
Irena Rindos
Hugo Vieira
Jim