Open Stack

And k8s has the benefit of already having been installed with certs that
had to get there somehow.. through a trust bootstrap.. usually SSH. ;)

Excerpts from Fox, Kevin M's message of 2017-10-09 17:37:17 +0000:
> Yeah, there is a way to do it today. it really sucks though for most users. Due to the complexity of doing the task though, most users just have gotten into the terrible habit of ignoring the "this host's ssh key changed" and just blindly accepting the change. I kind of hate to say it this way, but because of the way things are done today, OpenStack's training folks to ignore man in the middle attacks. This is not good. We shouldn't just shrug it off and say folks should be more careful. We should try and make the edge less sharp so they are less likely to stab themselves, and later, give OpenStack a bad name because OpenStack was involved.
> 

I agree that we could do better.

I think there _is_ a standardized method which is to print the host
public keys to console, and scrape them out on first access.

> (Yeah, I get it is not exactly OpenStack's fault that they use it in an unsafe manner. But still, if OpenStack can do something about it, it would be better for everyone involved)
> 

We could do better though. We could have an API for that.

> This is one thing I think k8s is doing really well. kubectl exec <pod>   uses the chain of trust built up from user all the way to the pod. There isn't anything manual the user has to do to secure the path. OpenStack really could benefit from something similar for client to vm.
> 

This is an unfair comparison. k8s is running in the user space, and as
such rides on the bootstrap trust of whatever was used to install it.