[v14] fix!: respect deny rules for access requests#34600
Merged
nklaassen merged 2 commits intobranch/v14from Nov 15, 2023
Merged
[v14] fix!: respect deny rules for access requests#34600nklaassen merged 2 commits intobranch/v14from
nklaassen merged 2 commits intobranch/v14from
Conversation
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.
atburke
approved these changes
Nov 14, 2023
zmb3
approved these changes
Nov 15, 2023
| // an AccessExplicitlyDenied error. | ||
| func IsAccessExplicitlyDenied(err error) bool { | ||
| var target *accessExplicitlyDenied | ||
| return errors.As(err, &target) |
Collaborator
There was a problem hiding this comment.
If we only need a book and don't care about the actual target error, can we use errors.Is instead?
Contributor
Author
There was a problem hiding this comment.
I think that would get the semantics wrong. I want to match any AccessExplicitlyDenied error regardless of the underlying/inner error, but errors.Is tests for equality with a specific value. Of course, I could make it work by implementing an Is method, but I think having to do that kind of shows that you're doing something non-standard.
public-teleport-github-review-bot
Bot
removed request for
fspmarshall and
jentfoo
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
3 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.
Backport #34438 to branch/v14