Conversation
There was a problem hiding this comment.
I think this is an important distinction, when a role explicitly denies something that means that no other role can allow access to it, even through an access request.
There was a problem hiding this comment.
I copied this text from the existing comment on app_labels, it seems much better
There was a problem hiding this comment.
I intentionally added some spaces in a few of these code snippets to allow line breaks in acceptable positions
5841d45 to
306401a
Compare
This commit adds documentation for the label expressions feature described in RFD 116.
306401a to
fcbc55f
Compare
ptgott
left a comment
There was a problem hiding this comment.
Approved with minor suggestions
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
|
|
||
| ```yaml | ||
| kind: role | ||
| version: v5 |
There was a problem hiding this comment.
Are label expressions available in rove v5?
| version: v5 | |
| version: v6 |
There was a problem hiding this comment.
They actually work fine all the way back to role v3. Our role versioning is weird, it really just changes the meaning of empty/default values, and we manually block some features in older versions, but I don't think there's any reason to block label expressions
| contains(user.spec.traits["teams"], labels["team"]) | ||
| ``` | ||
|
|
||
| The `<kind>_labels_expression` fields have the same purpose of the |
There was a problem hiding this comment.
You can only specify one of <kind>_labels or <kind>_labels_expression, right? Worth mentioning that here?
There was a problem hiding this comment.
You can specify both if you really want to, added a short blurb to explain that
Co-authored-by: rosstimothy <39066650+rosstimothy@users.noreply.github.com>
|
@nklaassen See the table below for backport results.
|
This commit adds documentation for the label expressions feature described in RFD 116.