Richard Bucker

major cloud-init weakness

Posted at — Sep 30, 2015

Now that you’ve wet your pants it’s not all that bad.

I continue to deep dive into CoreOS, RancherOS, and Docker. I’ve also been testing ideas with both Google Compute Engine and Digital Ocean. And a lot of things have been going badly.

The most recent hiccup was realizing that any changes to CoreOS’ configuration must be accompanied with a complete refresh of the nodes cloud-config file. While I have no experience with it I’m hoping that the enterprise CoreOS experience is better than my standalone.

Doing a complete CoreOS refresh while there is volume sharing etc with the host means that the cloud-init is very complicated. My development machine is configured with both a Bosun and Grafana containers. And then there is my devbox. Since containers have been known to crash from time to time I am sharing a volume with the host. Only some of that is problematic.

In some environments you might have multiple admins… and so the admin’s ssh keys would be installed in the cloud-config file. As a result the admin can login a little easier. There is an option to store a password too but that’s pretty much the same thing… The question is; what happens when that person leaves the organization? Is the OPS staff expected to redeploy every node having removed the credentials?

This, of course, is not too big of a problem when the target server is behind a firewall such as GCE. But when you use Digital Ocean there is no firewall. You have to create your own iptables or firewall instance. Using a shared admin key is not an option either. Various compliance bodies expect that each user have their own creds.

PS: if the preferred method for deploying users is cloud-config then that is the only way. Bypassing cloud-config would not be idempotent.