[benth]

You raise some good points, like the kubelet killing off pods in hopes of getting a new pod with juicier secrets associated with it, but nevertheless the ticket mentioned by the sibling comment (https://github.com/kubernetes/kubernetes/issues/40476) sounds like a property that Docker's secret handling already has. It would be great to see Kubernetes work this way, too.

Coincidentally, I'm working on a project that uses Kubernetes and it has a very locked down pod placement policy, so the attack you described would be significantly scoped down. But I don't think the same is true of most Kubernetes deployments.

[smarterclayton]

Defending the cluster from malicious nodes is not in the primary threat model of Kubernetes today. A malicious node can do many things, like lie about its capacity, scan container memory for juicy secrets, inject arbitrary outgoing or ongoing traffic, and in general be a jerk.

Securing nodes, preventing container escape, subdividing role access, constraining placement, limiting master surface area, and end to end audits have been the initial focus. Until those are in place, node secret access was less critical.

It is something that several folks are interested in working on soon.