UPSTREAM: <carry>: Remove write permissions on daemonsets from Kubernetes bootstrap policy

[enj]

Due to how daemonsets interact with the project node selector, we need to limit write access to them to the cluster admin.

Bug 1536304
Bug 1501514

Signed-off-by: Monis Khan mkhan@redhat.com

/kind bug
/assign @liggitt @deads2k @simo5 @smarterclayton
@openshift/sig-security

/cherrypick release-3.9

[simo5]

/lgtm
/hold
@openshift/sig-security PTAL and add more comments to cancel hold

[tnozicka]

I think it would be consistent to remove read permission as well otherwise it just more confusing. There is no reason regular user should even see a daemonset nor create it.

/cherrypick release-3.9

[openshift-cherrypick-robot]

@tnozicka: once the present PR merges, I will cherry-pick it on top of release-3.9 in a new PR and assign it to you.

In response to this:

I think it would be consistent to remove read permission as well otherwise it just more confusing. There is no reason regular user should even see a daemonset nor create it.

/cherrypick release-3.9

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[liggitt]

I think it would be consistent to remove read permission as well otherwise it just more confusing. There is no reason regular user should even see a daemonset nor create it.

no. oc get all will attempt to view daemonsets (they are included in the all category), and we don't want to cause errors for that command

[tnozicka]

@liggitt so if someone disables DS for their regular users on their cluster like Online; oc get all will break? Shouldn't we better fix the discovery?

Why should making security decision about permissions be restricted by a way how some command is implemented?

[liggitt]

@liggitt so if someone disables DS for their regular users on their cluster like Online; oc get all will break? Shouldn't we better fix the discovery?

Letting a user see daemonsets running in their namespace is not problematic.

[tnozicka]

Letting a user see daemonsets running in their namespace is not problematic.

Yes, it isn't problematic. It is also not ideal. But I can live with that.

[tnozicka]

removing just write lgtm

do we need that in 3.7? (do we use the same permission model from upstream there?)

/retest

[mfojtik]

/approve

The read permission is acceptable to me, as a user I want to see what runs in my namespace even if I can't create such resources.

@simo5 can we cancel the hold here?

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enj, mfojtik, simo5

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:

• test/testdata/OWNERS [enj,mfojtik]
• vendor/k8s.io/kubernetes/plugin/pkg/auth/OWNERS [mfojtik]

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

[simo5]

/hold cancel

[openshift-merge-robot]

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

[enj]

We pulled these in #17976 so this only needs to go back to 3.9.

[openshift-ci-robot]

@enj: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
ci/openshift-jenkins/gcp	a42347b	link	/test gcp

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[openshift-merge-robot]

Automatic merge from submit-queue.

[openshift-cherrypick-robot]

@tnozicka: new pull request created: #18977

In response to this:

I think it would be consistent to remove read permission as well otherwise it just more confusing. There is no reason regular user should even see a daemonset nor create it.

/cherrypick release-3.9

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.