Open Stack

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

dmakogon at mirantis.com


2014-02-11 22:58 GMT+02:00 Michael Basnight <mbasnight at gmail.com>:

> Denis Makogon <dmakogon at 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
> > dmakogon at mirantis.com
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140211/3582c7a3/attachment.html>