<div dir="ltr">Hello,<div><br></div><div>I believe that this discussion need actually be split into two parts: encryption algorithms and specific tools, and key management.</div><div><br></div><div>The implementation of actual encryption are specific for every project. We identified a number of blueprints which utilize encryption in one way or another:</div>




<div><div style="font-family:arial,sans-serif;font-size:13px"><a href="https://blueprints.launchpad.net/keystone/+spec/access-key-authentication" target="_blank">https://blueprints.launchpad.net/keystone/+spec/access-key-authentication</a><br>



</div><div style="font-family:arial,sans-serif;font-size:13px"><a href="https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-volumes" target="_blank">https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-volumes</a><br>



</div><div style="font-family:arial,sans-serif;font-size:13px"><a href="https://blueprints.launchpad.net/swift/+spec/encrypted-objects" target="_blank">https://blueprints.launchpad.net/swift/+spec/encrypted-objects</a><br>



</div><div style="font-family:arial,sans-serif;font-size:13px"><a href="https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes" target="_blank">https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes</a><br>



</div></div><div><br></div><div>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).</div>

<div><br></div><div style>Please, tell me if this sounds reasonable to you. Do you think this kind of discussion should take place at Summit?</div><div><br></div><div style>--<br>Best regards,</div><div style>Oleg</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 12:32 PM, Caitlin Bestler <span dir="ltr"><<a href="mailto:caitlin.bestler@nexenta.com" target="_blank">caitlin.bestler@nexenta.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div class="im">
    <div>On 2/13/2013 9:46 AM, Nate Reller
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div style="font-size:12pt;font-family:times new roman,new york,times,serif">
        <div>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.</div>
        <div><br>
          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.</div>
        <div style="font-style:normal;font-size:16px;background-color:transparent;font-family:times new roman,new york,times,serif"><br>
          -Nate</div>
        <div style="font-style:normal;font-size:16px;background-color:transparent;font-family:times new roman,new york,times,serif"><br>
        </div>
      </div>
    </blockquote></div>
    Something like this should always be pluggable, even if it requires
    editing configuration files.<br>
    Dashboard selection would also be nice, but would presume providing
    some text about what<br>
    the options were.<br>
    <br>
    In any case, the general rule of thumb I have followed on security
    issues is to allow the user<br>
    a great deal of flexibility, but to default high. Users who do not
    know how to configure their<br>
    security settings probably need them to be set high.<br>
    <br>
  </div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>