What's the motivation for this?  See also discussion in [1].

[1]: https://github.com/openshift/installer/issues/929

Ah, I raised the question in slack to Michal, didn't see he opened the GH issue, thus I filed this bug.
Motivation:
First, on the QE auto test side, in 3.x, master has /etc/origin/master/admin.kubeconfig, QE's auto test jenkins jobs retrieve the file from master to run cases that need system:admin. Now against nextgen env, our auto test cannot run those cases because the file path doesn't exist on master node.
Second, on user experience side, user executes `openshift-install create cluster ...` on some machine (named A), the machine A may be a VM or even a pod, once the machine is broken/deleted, the machine A's `auth/kubeconfig` disappears.
So, master nodes should keep a pre-set admin kubeconfig file path.

I have added motivation to github:

>If you have an automated (non-local) system it is actually rather hard to do thing properly if admin kubeconfig is not retrievable from master. In an automated system you'd have to archive that kubeconfig somehow, then know relationship between cluster and automated build, then also make sure unauthorized people cannot download it (e.g. people with only read access to builds).
> 
> It is much preferable if all cluster information can be discovered from master also for purposes of removing old clusters without searching for artifacts related to that particular cluster.

I don't think keeping admin cubeconfig on master poses any security problems. A root on master can mess up with service pods and etcd anyway so a determined abuser with root access can't be stopped anyway. It is just additional work to keep metadata about cluster external to the cluster and secured well enough. So it is more secure IMO to have things in master instead of externally.

I closed the discussion over on GitHub [1] after coming to a decision. I'm going to close this as well.

[1]: https://github.com/openshift/installer/issues/929