`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.
Louis Ruch
Hugo
Jeff Mitchell
Johan Brandhorst-Satzkorn
Irena Rindos
Timothy Messier
Jim
Todd KnightandJeff Mitchell
