OnApp cloud orchestration software we use adds one single authorized_key on
every VM provision. It does not matter whether its public or custom
template being built. That authorized_key relates to the private one used
by the cloud controller software and kept encypted on the controller
machine (being the most secure and isolated machine in whole cloud).
This key allows the controller to perform operations that require root file
system access _without_ shuting down VM. When the operation is requested by
the user the controller logs in to the VM and i.e. re-creates files
responsible for network configuration. If the controller cannot log in to
the VM due to the key being de-authorized or firewall blocking ssh - the
operation will fail. It is in no way critical tho as every such operation
does have a "forceful" equivalent, which shutdowns the VM to access its
file system directly from the hypervisor.
Summing up:
1. The key is installed by OnApp and its just the way it works.
2. The private key is very well protected, the point when an attacker
would gain access to the key probably means whole cloud exploitation.
3. At any time you can remove the key, the only drawback being forced to
reboot VM on some operations.