Skip to content
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

PSP plugin: allow authorizing via "use" verb in policy API group #60145

Merged

Conversation

php-coder
Copy link
Contributor

@php-coder php-coder commented Feb 21, 2018

What this PR does / why we need it:
In order to determine whether a service account/user has access to PSP, PodSecurityPolicy admission plugin tests whether a service account/user is authorized for "use" verb in extensions API group. As PSP is being migrated to policy API group, we need to support its new location. This PR adds such a support by checking in both API groups.

Which issue(s) this PR fixes:
Addressed to: kubernetes/enhancements#5
Follow-up to: #54933

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Feb 21, 2018
@php-coder
Copy link
Contributor Author

@liggitt @tallclair

  1. could you provide a feedback on that, is this how it should be? What else is needed (except unit tests).
  2. do we need a release note for this change?

CC @simo5

func authorizedForPolicy(info user.Info, namespace string, policyName string, authz authorizer.Authorizer) bool {
// Check against extensions API group first (for backward compatibility)
return authorizedForPolicyInAPIGroup(info, namespace, policyName, extensions.GroupName, authz) ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd actually flip this, check the new desired API group first, then fall back to the extensions API group. We definitely want to announce deprecation and move all the addons to the policy API group in 1.11, so we can remove this double check asap.

@liggitt
Copy link
Member

liggitt commented Feb 21, 2018

could you provide a feedback on that, is this how it should be? What else is needed (except unit tests).

I think a unit test that ensures permission via either API group grants you access is sufficient

do we need a release note for this change?

I would update the release note on the previous PR to include this change... we really want a single release note covering the changes people need to be aware of

@php-coder
Copy link
Contributor Author

/release-note-none

@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Feb 21, 2018
@php-coder
Copy link
Contributor Author

I would update the release note on the previous PR to include this change...

@liggitt Could you update it? (I see that you've already edited it once.)

If we're saying that PSP from extensions is deprecated then IMHO we don't need to mention that admissions plugin now has additional check for that. It's implied that we updated all the places for using a new API group, do we?

@liggitt liggitt added this to the v1.10 milestone Feb 21, 2018
@liggitt liggitt added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. kind/feature Categorizes issue or PR as related to a new feature. sig/auth Categorizes an issue or PR as relevant to SIG Auth. status/approved-for-milestone labels Feb 21, 2018
@liggitt liggitt self-assigned this Feb 21, 2018
@tallclair
Copy link
Member

I agree with @liggitt 's comments. I think the current release note is sufficient.

@tallclair
Copy link
Member

Actually, should we mark it as action-required? Or wait until next release when it's actually required?

@liggitt
Copy link
Member

liggitt commented Feb 21, 2018

I updated the previous release note to indicate authorizations should be updated to refer to the policy API group after upgrade.

@tallclair
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 22, 2018
@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Feb 22, 2018
@k8s-github-robot k8s-github-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 22, 2018
@liggitt
Copy link
Member

liggitt commented Feb 22, 2018

/lgtm
remove WIP?

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 22, 2018
@php-coder php-coder changed the title [WIP] PSP plugin: allow authorizing via "use" verb in policy API group PSP plugin: allow authorizing via "use" verb in policy API group Feb 22, 2018
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 22, 2018
@php-coder
Copy link
Contributor Author

@liggitt Updated, thanks to remind me.

@eparis PTAL

@eparis
Copy link
Contributor

eparis commented Feb 23, 2018

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eparis, liggitt, php-coder, tallclair

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 23, 2018
@k8s-github-robot
Copy link

/test all [submit-queue is verifying that this PR is safe to merge]

@k8s-github-robot
Copy link

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here.

@k8s-github-robot k8s-github-robot merged commit aaeccd3 into kubernetes:master Feb 23, 2018
@php-coder php-coder deleted the psp_authz_via_policy_group branch February 23, 2018 15:58
k8s-github-robot pushed a commit that referenced this pull request Feb 28, 2018
Automatic merge from submit-queue (batch tested with PRs 60475, 60514, 60506, 59903, 60319). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

E2E: add tests for PSP in the policy API Group

**What this PR does / why we need it**:
E2E tests were added for testing PSP from the "policy" API Group. They are similar to the tests for PSP from the "extensions" API Group.

**Which issue(s) this PR fixes**:
Addressed to: kubernetes/enhancements#5
Follow-up to: #54933 and #60145
@@ -354,11 +355,19 @@ func isAuthorizedForPolicy(user, sa user.Info, namespace, policyName string, aut
}

// authorizedForPolicy returns true if info is authorized to perform the "use" verb on the policy resource.
// TODO: check against only the policy group when PSP will be completely moved out of the extensions
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@liggitt @tallclair For how long we need to support PSP in extenstions API group?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think as long as the API is still there. I'm not sure what the policy is for removing resources from extensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. release-note-none Denotes a PR that doesn't merit a release note. sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants