rules review endpoint for other user #10611
Conversation
|
[test] |
| @@ -80,8 +80,22 @@ os::cmd::expect_success_and_text 'oc policy can-i --list' 'get update.*imagestre | |||
| os::cmd::expect_success_and_text 'oc policy can-i create pods --all-namespaces' 'yes' | |||
| os::cmd::expect_success_and_text 'oc policy can-i create pods' 'yes' | |||
| os::cmd::expect_success_and_text 'oc policy can-i create pods --as harold' 'no' | |||
| os::cmd::expect_failure 'oc policy can-i create pods --as harold --user harold' | |||
There was a problem hiding this comment.
Especially with the influx of these tests, can-i should have it's own suite in it's own file, not here.
There was a problem hiding this comment.
Could possibly use os::cmd::expect_failure_and_text in some of these tests as well.
openshift-bot
added
the
needs-rebase
|
@smarterclayton ping (api review) |
| } | ||
| } | ||
|
|
||
| func (c *subjectRulesReviews) Create(subjectRulesReview *authorizationapi.SubjectRulesReview) (result *authorizationapi.SubjectRulesReview, err error) { |
There was a problem hiding this comment.
Why the named return values?
Consistency with the rest. These all die when we switch to generated.
|
@mfojtik this seems reasonable to me. |
|
LGTM from a CLI perspective. |
|
Still requesting the test bits |
| return ret, nil | ||
| } | ||
|
|
||
| func GetEffectivePolicyRules(ctx kapi.Context, ruleResolver rulevalidation.AuthorizationRuleResolver, clusterPolicyGetter client.ClusterPolicyLister) ([]authorizationapi.PolicyRule, []error) { |
|
Are these APIs now fractal in that we are creating all possible intersections of "target" / "data"? |
|
|
||
| // SubjectRulesReviewSpec adds information about how to conduct the check | ||
| type SubjectRulesReviewSpec struct { | ||
| // User is optional. At least one of User and Groups must be specified. |
There was a problem hiding this comment.
Why not an array of Subjects? Since this is SubjectRulesReview
There was a problem hiding this comment.
I.e. I'd probably want to use this on ServiceAccounts
There was a problem hiding this comment.
Why not an array of Subjects? Since this is SubjectRulesReview
I was matching SubjectAccessReviewSpec. I would expect these look the same in v1 and we'd change them all in v2.
deads2k
force-pushed
the
rules-review
branch
from
3083b56 to
de1319e
Compare
openshift-bot
removed
the
needs-rebase
deads2k
force-pushed
the
rules-review
branch
from
de1319e to
00c8f7e
Compare
|
Evaluated for origin test up to 00c8f7e |
|
continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/9308/) |
|
@deads2k i will have a look today |
|
Origin Action Required: Pull request cannot be automatically merged, please rebase your branch from latest HEAD and push again |
openshift-bot
added
the
needs-rebase
Adds a
subjectrulesreviewsresource for looking at the rules on another user. project-admins and above have the power and can use it to see what permission a given user and/or groups have in their project.Also adds options to
oc policy can-ito wire the functionality together.@openshift/api-review