Add a KEP for Node-Scoped Daemonset

[haiyanmeng]

This KEP describes a mechanism restricting a DaemonSet pod to only managing the resources that reside on the same node as the DaemonSet pod.

Tracking issue: the 4.c part of kubernetes/kubernetes#62747

[k8s-ci-robot]

Hi @haiyanmeng. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: haiyanmeng
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: liggitt

If they are not already assigned, you can assign the PR to them by writing /assign @liggitt in a comment when ready.

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:

• keps/sig-auth/OWNERS

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

[haiyanmeng]

/cc @tallclair

[janetkuo]

/ok-to-test

[haiyanmeng]

/cc @janetkuo

[janetkuo]

/sig apps

[tallclair]

Thanks @haiyanmeng ! Awesome job for your first ever KEP. Looking forward to discussing at next sig-auth

[tallclair]

I thought it could just fetch it directly from the graph?

[haiyanmeng]

Do you mean the resource graph used in NodeAuthorizer?

Since NodeRestriction can inspect the request objects, there is no need to check the resource graph.

[tallclair]

Nodes from 2019-04-17 sig-auth:

• Consider separating the authorization & admission piece. It looks like the admission piece doesn't need the graph, and is more node specific. Admission could be handled with policy controls (e.g. gatekeeper)
• Intersecting permissions has been previously discussed, and might make sense here - would intersecting service account & kubelet permissions be sufficient?
• Some questions about whether this is sufficiently generic, and how it applies to non-DaemonSet workloads.
  • Note(tallclair): I don't see the use case for non-daemonset workloads. IMO this only makes sense when the workload is node-aware

Anything else I missed?

[haiyanmeng]

/cc @deads2k @smarterclayton

[haiyanmeng]

Based on the feedback from last week's sig-auth meeting, I updated the KEP. The main changes are:

1. added a Use Cases section and Auternatives section;
2. updated the Proposal section. In short, the new solution allows the DaemonSet owners to specify a list of resource types whose access permissions should be node-scoped; during the authorization step, the requests from node-scoped daemonset pods will go through both NodeAuthorizer and RBAC, and the request must be allowed by the NodeAuthorizer first before RBAC authorizes the request. If NodeAuthorizer does not explicitly allow the request, the request will be denied directly.

Please let me know if you have any suggestions.

[enj]

I am still trying to grasp all of the pieces here, but adding a new field to SA seems wrong to me. Could this be handled via the token request API?

[mikedanese]

Both these options feel like authorization bleeding out of authorization. We unfortunately do this in various places already but it hurts our ability to build authorization features, e.g. can-i explain, delegated authz.

[haiyanmeng]

As discussed in the sig-auth meeting, the short-term plan to achieve node-scoped daemonsets is to run daemonsets with kubelet credentials, while we work on a long term plan, which will avoid tangling authorizers together and may conditionalize authorization.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.

[cheyang]

@haiyanmeng May I ask if we'd like to use Node-Scoped Daemonset. What's the recommended way? Still with kubelet credentials?