cc @kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests

Do we have any existing APIs that filter list and watch results like this?

Would it be reasonable to implement restrictions for gets on {secrets, configmaps, persistentvolumeclaim}, and updates on pods, then defer futher restrictions on {list,watch} operations once we figure out filtering? Or do nodes {list,watch} secrets today?

Or do nodes {list,watch} secrets today?

they do not

Do we have any existing APIs that filter list and watch results like this?

Yes, label and field selection filters can be applied and they are available (and restrictable) on an http request, so it would be consistent to enforce it with an authorizer.

I'm assuming the motivation here is to prevent a node compromise from being equivalent to a cluster compromise, by limiting the potential damage to only resources scheduled (transitively) to the node. Given this goal, what's to stop an attacker from simply updating a pod spec to reference the resource they want access to? An obvious solution is to prevent the node from posting anything other than status updates, but this would break the implementation of static pods on the node (via mirror pods).

Are there any other motivations to this proposal, or do we need to tackle these issues first?

I'm assuming the motivation here is to prevent a node compromise from being equivalent to a cluster compromise, by limiting the potential damage to only resources scheduled (transitively) to the node.

Correct.

Given this goal, what's to stop an attacker from simply updating a pod spec to reference the resource they want access to?

Pod spec is immutable. I would see nodes as being limited to:

• create mirror pod bound to self (which already cannot reference secrets)
• update pod status for pod bound to self

An obvious solution is to prevent the node from posting anything other than status updates, but this would break the implementation of static pods on the node (via mirror pods).

Mirror pods are not allowed to reference secrets

Cool, good to see this is already in place. Perhaps we should extend the limits to prevent certain volume types as well?

Would this allow something like "watch all secrets in all namespaces" to server-side filter and return only secrets on this node? Or would it be an error, and we would have to set up N individual watches ourself?

Would this allow something like "watch all secrets in all namespaces" to server-side filter and return only secrets on this node? Or would it be an error, and we would have to set up N individual watches ourself?

For lists/watches, the request for ACL-filtered secrets would likely need to be explicit (possibly something explicitly requesting "secrets for pods for node X", which is gorpy to express, or bespoke resource endpoints for nodes, which is gorpy to add for just one type of user). Adding ACL filtering to existing list/watch APIs would be... unexpected.

We'd like to find a way to let nodes watch the secrets they're supposed to have access to instead of making them poll or manage lots of individual watches, but even protecting the existing GET requests based on the node->pod->secret relationship would be an improvement.

We'd like to find a way to let nodes watch the secrets they're supposed to have access to instead of making them poll or manage lots of individual watches, but even protecting the existing GET requests based on the node->pod->secret relationship would be an improvement.

I agree. Though, since we would like to change kubelet to actually "list+watch" secrets, configmaps, etc., I'm going to put together a proposal for this part once I'm done with 1.6 work. I will focus more on that part, but this will be strictly related to this one.
And I agree that the request should be "explicitly asking for my secrets" not implicit filtering. I will try to put some proposal together in a week or two.

So I created the initial draft of my proposal here: kubernetes/community#443
It still has some TODOs to think about it, and I will work on improving the doc itself more towards end of 1.6, but the high level idea should probably be roughly clear.

Can we dedupe this with kubernetes/enhancements#279 ?

closing in favor of kubernetes/enhancements#279