fix!: respect deny rules for access requests#34438
Merged
Conversation
nklaassen
commented
Nov 10, 2023
Comment on lines
106
to
107
Contributor
Author
There was a problem hiding this comment.
This was here to make trace.IsAccessDenied work, but is no longer necessary now that aggregate errors support Is/As since gravitational/trace#77
jentfoo
approved these changes
Nov 10, 2023
Access Request follow their own set of RBAC rules.
Usually, none of the typical create/read/list/delete verbs are required
in any user's roles.
Access is handled via custom rules based on the allow.request, deny.request,
allow.review_requests, and deny.review_requests role fields.
The create/read/list/delete verbs commonly used for other resources are
usually all or nothing (barring `where` expressions), but a more nuanced
set of rules apply to access requests. E.g. users should always be
allowed to see access requests that they created or are allowed to
review, without being allowed to see other access requests in the
cluster.
This seemed mostly logical once you thought about it long enough, but
one detail that has been lacking so far is that explicit deny rules in
the user's roles have no effect at all, even though explicit allow rules
grant god-mode access to create or view any access requests in the
cluster.
Even with the following role, you could still create and view
access requests:
```yaml
kind: role
version: v6
metadata:
name: example
spec:
allow:
request:
roles: ["*"]
review_requests:
roles: ["*"]
deny:
rules:
- resources: ["access_request"]
verbs: ["create", "read", "list"]
```
This commit makes any explicit deny rules actually take effect.
Fixes gravitational/customer-sensitive-requests#103
changelog: Respect explicit deny rules for Access Requests.
nklaassen
force-pushed
the
nklaassen/request-rbac
branch
from
d0eaa62 to
8de1376
Compare
fspmarshall
approved these changes
Nov 14, 2023
Contributor
Author
|
friendly ping @atburke |
atburke
approved these changes
Nov 14, 2023
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
|
@nklaassen See the table below for backport results.
|
nklaassen
added a commit
that referenced
this pull request
Nov 14, 2023
Backport #34438 to branch/v12
This was referenced Nov 14, 2023
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Nov 16, 2023
* [v12] fix!: respect deny rules for access requests Backport #34438 to branch/v12 * test fix * chore: Bump gravitational/trace to v1.3.0 (#30064) * chore: Bump gravitational/trace to v1.3.0 * Replace `trace.IsEOF` with `errors.Is` * Fix IsPermanentEmitError * chore: update gravitational/trace to v1.3.1 --------- Co-authored-by: Alan Parra <alan.parra@goteleport.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Access Requests follow their own set of RBAC rules. Usually, none of the typical create/read/list/delete verbs are required in any user's roles. Access is handled via custom rules based on the
allow.request,deny.request,allow.review_requests, anddeny.review_requestsfields in the role spec.The create/read/list/delete verbs commonly used for other resources are usually all or nothing (barring
whereexpressions), but a more nuanced set of rules apply to access requests. E.g. users should always be allowed to see access requests that they created or are allowed to review, without being allowed to see other access requests in the cluster.This seemed mostly logical once you thought about it long enough, but one detail that has been lacking so far is that explicit deny rules in the user's roles have no effect at all, even though explicit allow rules grant god-mode access to create or view any access requests in the cluster.
Even with the following role, you could still create and view access requests:
This commit makes any explicit deny rules actually take effect.
Fixes https://github.com/gravitational/teleport-private/issues/298
changelog: Respect explicit deny rules for Access Requests.