Proposal: Isolate kubelet from etcd

Discusses the current security risks posed by the kubelet->etcd pattern
and discusses some options.

Triggered by #846 and referenced in #859

Does not have to be merged, for discussion and review
It seems that the real issue is controlling the view of the state information from each point:

1) minion host processes should only see either cluster-common portions or those destined explicitly to that minion.
2) contained processes should only see common or explicit addressed information

It should not be possible for a process on minion-E to impersonate a process on minion-A...  (Which includes processes inside containers)
It should not be possible for a process in container-E to impersonate a process in container-A.. anywhere in the cluster.

Since etc is a state replication system its general mode of operation is to replicate the entire state tree.  This means that limiting access to portions not destined for minion-E must not be replicated on minion-E or they become vulnerable.  Access control and comprehensive state replication are at odds.

Is this the objection to #4? 

If so, then it appears to me that the only solution is to replace etcd completely with something which is functionally disjoint from the minion hosts and which provides access only through an identified/authenticated/encrypted network interface. Each minion and each container will require a distinct authenticated connection to ensure that they are granted access only to information they are granted.

I think though that the "api-server" will need to provide for two different sets of authenicated "users".  The internal "users" listed above will consume and produce state information.  The external "users" (the kubecfg client and any machine clients) will require different authentication and access and will have a different command set.  I worry about combining these two into a single service.