-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adding where
and actions
section scripts in rules
#1222
Conversation
where
and actions
section scripts in ruleswhere
and actions
section scripts in rules
retest this please |
// Context is a default rule context used in teleport | ||
type Context struct { | ||
// User is currently authenticated user | ||
User User |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If users can directly access the internal representation of Teleport objects like this contains(user.spec.traits["groups"], "prod")
, that will make migration difficult if/when we change the internal representation of a resource.
For example if we remove or rename traits
in the future, roles will break. No only that, because where
is a string, migrating it will be non-trivial.
What do you think about a Context with predefined fields in it. That way migrations will be easier in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand your suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@russjones these are not internal representation of teleport objects, but the API of the versioned objects exposed to the user.
The following logic has been added to the roles:
Behavior:
The following is supported/not supported now:
contains
function is supported and has following signature:euqals
function is supported and has following signature:user
and provides access to the current user to all fields defined in the manifest as validated by schema:log
is supported with the following signatureresource
property is supported but not currently initialized, as we have to pass the resource for every action, we may do it later when the need arises in certain scenarios.Note for @alex-kovoy : the web/roleaccess.go is completely broken now, I rely on you refactoring it.