It is the most important step that you can package containers without having to know the production secrets and to have a "standard" was to retrieve them.
No one, without production access, has a way to obtain them.
> Currently, anyone with root on any node can read any secret from the apiserver, by impersonating the kubelet
> If multiple replicas of etcd are run, then the secrets will be shared between them. By default, etcd does not secure peer-to-peer communication with SSL/TLS, though this can be configured.
We usually recommend subdividing the node acls by namespace when running disjoint node sets (where tenant A can't schedule onto tenant B's nodes). More fiddly than it has to be in Kubernetes today.
The real solution is of course to limit what nodes can see - I won't say it's trivial, but it's an O(1) check based on the pods scheduled on that node.
That's partially why we (openshift) just don't allow containers to run as root by default - it sucks for new users (most images assume root) but it dramatically lowers the risk of compromise across the board in any scenario with multi-tenancy. Agree that with isolated nodes per tenant you wouldn't have this issue, which is a more straightforward RBAC story.