Open Stack

Hello,

I believe that this discussion need actually be split into two parts:
encryption algorithms and specific tools, and key management.

The implementation of actual encryption are specific for every project. We
identified a number of blueprints which utilize encryption in one way or
another:
https://blueprints.launchpad.net/keystone/+spec/access-key-authentication
https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-volumes
https://blueprints.launchpad.net/swift/+spec/encrypted-objects
https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes

All these blueprints involve some key management, and it seems reasonable
to implement it as a shared component. Where does it belongs is a
discussion topic. Our understanding is that Keystone API could be extended
with new resource keys/ to proxy keys operations with pluggable back-end
drivers (much like Identity or Catalog).

Please, tell me if this sounds reasonable to you. Do you think this kind of
discussion should take place at Summit?

--
Best regards,
Oleg


On Wed, Feb 13, 2013 at 12:32 PM, Caitlin Bestler <
caitlin.bestler at nexenta.com> wrote:

>  On 2/13/2013 9:46 AM, Nate Reller wrote:
>
>  Our intent was not to limit which encryption algorithms to use or to
> propose a minimum standard.  We needed to pick a default implementation to
> use for the Grizzly release.  We did not have enough time to make the
> algorithm configurable, so we needed to pick a default for the release.
>
> In the future we would like to support many different algorithms and key
> sizes.  We are imagining the user inputting which algorithm and key size
> they would like to use via the dashboard.  The administrators of the cloud
> would be responsible for configuring the dashboard and other components to
> report which encryption algorithms are available.  This will depend upon
> their cloud, and the encryption algorithm and key sizes will likely be
> dictated by the features supported by the compute nodes.
>
> -Nate
>
>   Something like this should always be pluggable, even if it requires
> editing configuration files.
> Dashboard selection would also be nice, but would presume providing some
> text about what
> the options were.
>
> In any case, the general rule of thumb I have followed on security issues
> is to allow the user
> a great deal of flexibility, but to default high. Users who do not know
> how to configure their
> security settings probably need them to be set high.
>
>
> _______________________________________________
> 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/20130213/9774c544/attachment.html>