Hi Nico,
You and I completely agree that unexpected discrepancies often cause problems, break workflows, and make people hate security changes. I've been a Debian developer for over 13 years and a UNIX sysadmin for longer than that. There are many cases where I've made arguments similar to yours inside Google, sometimes even mentioning "knife ssh" itself (yes I've used Chef), and we're more compatible with customers' non-GCE automation because of such arguments.
Despite all of that, adding this account management daemon in GCE makes sense, as do the other carefully chosen integration bits we add. Our account daemon can certainly be disabled without harm (e.g. via systemctl in CentOS 7), doesn't interfere with UNIX ways of working, and doesn't dictate what we do about the root account. It's even careful not to remove keys which were added separately by users, distinguishing carefully via comment lines. All of the software we add is of course free and open source software, typically under the Apache License 2.0, and also typically human-readable Python, shell, systemd unit files, or the like. Some of our software is even packaged in RPMs (built via a hacky internal process); we do plan to reach out to coordinate proper RPM packaging and integration into a suitable CentOS repository.
Regarding your specific concerns about root's passwd data, we don't change that. I forget whether we change CentOS's root SSH login setting; we do change a few other things like disabling password SSH auth and putting in some connection keepalive settings, but it's quite close to stock config. We try to keep our deviations justifiable, and if you think any are not, we'd like to hear about them. :) As one example justification, the SSH connection keepalive is because TCP connections that remain idle too many minutes will get dropped by the GCE firewall.
- Jimmy
We aren't changing root's passwd data.