-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
Add authz to psp admission #33080
Add authz to psp admission #33080
Conversation
@kubernetes/sig-auth This is saying you can create pods if you can That means that I cannot view all the PodSecurityPolicies so see which ones I want to ask my cluster admin to use. What if the verb was something distinctive. I like "use". Then you can give people read permission without allowing them to match the policy. Bonus points if there is a "use" subresource on the PodSecurityPolicy object that returns 200 if you are authorized to use that PSP, and 403 if you are not. Double bonus points if there is a "match" subresource on a PodSecurityPolicy object that takes a Pod and returns 200, plus a JSON message that says "match: true" or "match: false". |
Should have said this first: I love that this is getting finished up. Thank you for sending it. |
Agree that |
@alex-mohr @roberthbailey @cjcullen This PR would make it able to be per-user, which is interesting. You could allow an addon-adder-user to create hostDir containers, but not allow ordinary users to do so. Robert we chatted about this friday. This requires some authz support for the new "use" verb. |
19992a8
to
8992e27
Compare
@erictune @liggitt - updated this to use "use" as the verb. Since this is a synthetic check it doesn't require any plumbing so it's just matching what is in admission to what is in policy. Easy to change if "use" isn't good. Also added an example walk through of using PSP with RBAC to allow creation of privileged containers since it was referred to in #33080 (comment). PTAL |
Will take these as additional issues so this doesn't grow too much larger since it's at XL
Edit: #34963 |
} | ||
|
||
return matchedPolicies, nil | ||
} | ||
|
||
// authorizedForPolicy returns true if info is authorized to perform a "get" on policy. | ||
func authorizedForPolicy(info user.Info, policy *extensions.PodSecurityPolicy, authz authorizer.Authorizer) bool { | ||
if info == nil { |
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.
user info is nil when you hit the API via the unsecured port (no auth filter populates user info). would you expect that to return unauthorized for everything or authorized for everything?
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 would expect it to return unauthorized if the PSP plugin was enabled. Other opinions?
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.
that means that if there were PSPs present, no one could create pods against the unsecured port, which seems wrong
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.
changed to return true
attr := authorizer.AttributesRecord{ | ||
User: info, | ||
Verb: "use", | ||
Namespace: policy.Namespace, |
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.
PSP is cluster-scoped, so policy.Namespace isn't meaningful here. Would it make sense to check if the user is allowed to use the named PSP in the namespace where they are trying to perform the action (the pod namespace)? That would let you grant someone use of a particular PSP in a particular namespace, or cluster-wide.
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.
this is interesting but a fundamental change. I can definitely see the benefit of allowing ns admins to create more restrictive PSPs and granting access there but it would require some other changes and maybe some discussion on whether folks actually want to admin policy this way. Will take a note to discuss
matchedPolicies := make([]*extensions.PodSecurityPolicy, 0) | ||
|
||
for _, c := range store.List() { | ||
constraint, ok := c.(*extensions.PodSecurityPolicy) | ||
if !ok { | ||
return nil, errors.NewInternalError(fmt.Errorf("error converting object from store to a pod security policy: %v", c)) | ||
} | ||
matchedPolicies = append(matchedPolicies, constraint) | ||
|
||
if authorizedForPolicy(user, constraint, authz) || authorizedForPolicy(sa, constraint, authz) { |
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.
now that user factors into which policies are allowed, a different set could be selected on update than on create. on update, PSPs cannot mutate the pod spec, they simply need to pass/fail the pod as-is. that means splitting the selection/defaulting/validation steps, and skipping the defaulting step on update. can be a follow up, but needs to be done.
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.
be sure to open the follow-up issue to track
fsGroup: | ||
rule: RunAsAny | ||
runAsUser: | ||
rule: RunAsAny |
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.
doesn't seem very restricted :)
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.
the only difference here was privileged true|false for demo purposes of showing RBAC, not capabilities of the PSP. I can make it a "full" restricted PSP if you think that provides any value.
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.
people copy examples more than you'd think. I would be explicit with privileged: false
, limit volumes to the same volumes our restricted scc does, and maybe MustRunAsNonRoot?
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.
updated
apiVersion: rbac.authorization.k8s.io/v1alpha1 | ||
kind: ClusterRole | ||
metadata: | ||
name: restrictedPSP |
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.
restricted-psp-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.
fixed
apiVersion: rbac.authorization.k8s.io/v1alpha1 | ||
kind: ClusterRole | ||
metadata: | ||
name: privilegedPSP |
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.
privileged-psp-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.
fixed
kind: ClusterRole | ||
name: restrictedPSP | ||
--- | ||
# cluster-writer grants cluster-writer role to system:authenticated. |
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'd rather limit the example to psp-related roles/rolebindings
#34729 added admin/edit/view roles to bootstrapping? maybe use those in the examples instead?
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.
edit is exactly what I was shooting for, will rebase and update
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.
changed to bind edit to the system:authenticated
@pweil- status on this for code freeze? |
Feedback will be finished up shortly. |
Should this have 1.5 milestone on it? |
8992e27
to
1dc3fa5
Compare
@erictune I'd like to get it added to 1.5 @liggitt - feedback addressed. However, in testing I found some issues related to #33966 when rbac is enabled. It appears that all components are now using the secure port. When rbac is enabled there are no bootstrap policies that give the kubelet, controller-manager, and other infra access to the resources they need. Second commit is a hack to fix it so I could test but that needs resolved before this is merged. I think we should just go ahead and add the policies (cc @deads2k @dims @sttts) |
Jenkins verification failed for commit 1dc3fa52d7b1fdf1a25b50c3f7fb2ad992d375d0. Full PR test history. The magic incantation to run this job again is |
@pweil- adding the policies sounds right. Where and how? |
We have a bootstrap policy now, like openshift. Here's a pull adding node permissions: #36155 . For the controllers, I think we want to add them at the same time we segment them by controller. For now, the controller effectively wants to be in the |
removing the local-up-cluster commit based on conversations with @liggitt to unblock this PR. The walk through will have issues until resolved but I think it's still valuable to get in. |
cbbb83c
to
7db7924
Compare
added tests for nil user and nil SA |
@k8s-bot node e2e test this hrm, node test is marked as failed and the details show it is still running. Giving it another shot.. |
@liggitt tests are green if you want to apply milestones/labels |
bump, ready for any additional sign off, comments, or having labels applied and being merged. |
@derekwaynecarr FYI |
Tagged. Can you fill out the description a little more for people looking up the release note? |
updated description |
|
||
### Roles and bindings | ||
|
||
In order to a `PodSecurityPolicy` a user must have the ability to perform the `use` verb on the policy. |
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.
What does it mean to "peform the use
verb on a policy?
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 understand after reading the code, but I think you should explain it here for the uninformed user.
volumes: | ||
- '*' | ||
|
||
``` |
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.
The docs repo has a syntax for embedding files in docs. Do you know whether that works here?
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.
No, unfortunately I don't think so. I found github/markup#172 (comment) which mentions it is not allowed due to security concerns.
Release-czar approved post-code freeze merge--This was LGTMed and in the merge-queue at code freeze time for 1.5. Leaving 1.5 milestone to let it gets merged after code freeze. |
7db7924
to
bbe9c8f
Compare
@timstclair added some more wording about use granting access to use the policy but nothing else and that it is specific to PSP. If you're ok with this please reapply labels. Thanks for the feedback! |
Jenkins unit/integration failed for commit bbe9c8f. Full PR test history. The magic incantation to run this job again is |
Jenkins GCE Node e2e failed for commit bbe9c8f. Full PR test history. The magic incantation to run this job again is |
@k8s-bot node e2e test this |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue |
Add authz integration to PSP admission to enable granting access to use specific PSPs on a per-user and per-service account basis. This allows an administrator to use multiple policies in a cluster that grant different levels of access for different types of users.
Builds on #32555. Second commit adds authz check to matching policy function in psp admission.
@deads2k @sttts @timstclair
This change is