The OnApp cloud orchestration software we use adds one single authorised_key on every VM provision. It does not matter whether its public or custom template being built. That authorised_key relates to the private one used by the cloud controller software and kept encrypted on the controller machine (being the most secure and isolated machine in the whole cloud).

This key allows the controller to perform operations that require root file system access _without_ shutting down the VM. When the operation is requested by the user, the controller logs in to the VM and re-creates files responsible for network configuration. If the controller cannot log in to the VM due to the key being de-authorised or firewall blocking SSH - the operation will fail. It is in no way critical though as every such operation does have a 'forceful' equivalent, which shutdowns the VM to access its file system directly from the hypervisor.

Summing up:

• The key is installed by OnApp and its just the way it works.
• The private key is very well protected. The point when an attacker would gain access to the key probably means entire cloud exploitation.
• At any time, you can remove the key, the only drawback is being forced to reboot VM on some operations.