On 04/26/2016 09:32 AM, Daniel P. Berrange wrote:
IMHO encrypting oslo config files is addressing the wrong problem. Rather than having sensitive passwords stored in the main config files, we should have them stored completely separately by a secure password manager of some kind. The config file would then merely contain the name or uuid of an entry in the password manager. The service (eg nova-compute) would then query that password manager to get the actual sensitive password data it requires. At this point oslo.config does not need to know/care about encryption of its data as there's no longer sensitive data stored.
at the end of the day, if someone is on the machine where they can read those config files, they are on that machine where they can run any Python code they want which itself can be exactly the code in the openstack app that contacts this password service and gets the same information. Or put another way, nova-compute still needs a password or key of some kind to connect to this password service anyway.
If what we're going for as far as passwords in config files is that they don't get committed to source repositories or copied out to public places, then fine, store them "somewhere else" just to note that these are special values. But as far as someone on the machine (assuming per-user permissions to read the same files that the app can see have been acquired), there's always a key/password/token needed to get to "the password service", so they have access. The best you can do is run some closed-source executable that has private keys buried within it, to at least make this attack more difficult, or if you are really looking for something inconvenient, an administrator has to manually type in a passphrase when starting up the services. But we're using open source, source-code-present Python and I don't think we're doing passphrase-on-startup. So being on the box means, you have the passwords.
Regards, Daniel
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
