As we decided at meeting, we wouldn't keep our own implementations of security stuff, we'll use Barbican as single entry point of delivering secrets. I hadn't talked with Barbican team, but since oslo-incubator will (someday) release oslo.crypto lib for all projects, i think that adding implementation of new RFC to crypto is a good idea, it would be easy to re-use it in barbican later and then i will use barbican functionality in trove for security improvement.
Best regards, Denis Makogon Mirantis, Inc. Kharkov, Ukraine www.mirantis.com www.mirantis.ru dmako...@mirantis.com 2014-02-11 22:58 GMT+02:00 Michael Basnight <mbasni...@gmail.com>: > Denis Makogon <dmako...@mirantis.com> writes: > > > Goodday, OpenStack DВaaS community. > > > > > > I'd like to start conversation about guestagent security issue > related > > to backup/restore process. Trove guestagent service uses AES with 256 bit > > key (in CBC mode) [1] to encrypt backups which are stored at predefined > > Swift container. > > > > As you can see, password is defined in config file [2]. And here > comes > > problem, this password is used for all tenants/projects that use Trove - > it > > is a security issue. I would like to suggest Key derivation function [3] > > based on static attributes specific for each tenant/project (tenant_id). > > KDF would be based upon python implementation of PBKDF2 [4]. > Implementation > > can be seen here [5]. > > I do not want to see us writing our own crypto code in Trove. Id much > rather us use barbican for this, assuming it fits the bill. Lets do some > research on barbican before we go write this all. > > > > > Also i'm looking forward to give user an ability to pass password for > > KDF that would deliver key for backup/restore encryption/decryption, if > > ingress password (from user) will be empty, guest will use static > > attributes of tenant (tenant_id). > > > > To allow backward compatibility, python-troveclient should be able to > pass > > old password [1] to guestagent as one of parameters on restore call. > > > > Blueprint already have been registered in Trove launchpad space, [6]. > > > > I also foresee porting this feature to oslo-crypt, as part of security > > framework (oslo.crypto) extensions. > > Again, id rather see us use barbican for this instead of creating > oslo-crypt. > > > > > Thoughts ? > > > > [1] > > > https://github.com/openstack/trove/blob/master/trove/guestagent/strategies/backup/base.py#L113-L116 > > [2] > > > https://github.com/openstack/trove/blob/master/etc/trove/trove-guestagent.conf.sample#L69 > > [3] http://en.wikipedia.org/wiki/Key_derivation_function > > [4] http://en.wikipedia.org/wiki/PBKDF2 > > [5] https://gist.github.com/denismakogon/8823279 > > [6] https://blueprints.launchpad.net/trove/+spec/backup-encryption > > > > Best regards, > > Denis Makogon > > Mirantis, Inc. > > Kharkov, Ukraine > > www.mirantis.com > > www.mirantis.ru > > dmako...@mirantis.com > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev