<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 3:33 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From what I can tell, Keycloak is an Identity provider, not a secret store?<br>
<br></blockquote><div>Yes! I should explain more detailed. </div><div><br></div><div>CloudBand is a big enterprise system for SDN and OpenStack is a part of it. The default Identity provider of the system is Keycloak. </div><div>Currently Glare is used there not as a part of OpenStack deployment, but as a standalone service outside of OpenStack.</div><div>For this reason earlier this year we implemented Keycloak auth middleware for the server and authentication mechanism in the client,</div><div>i.e. we can use Keycloak instead of Keystone.</div><div><br></div><div><div>The decision regarding the secrets was taken, on the grounds that Barbican does not have such ability, and it's tightly attached</div><div>to Keystone. Moreover it was not difficult to implement the plugin for Glare.</div><div>As I said - originally this is a private plugin, which was decided to opensource for the OpenStack community. If this is not required, then</div><div>we can always cancel it. I don't see any problems with this.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-jay<span class="gmail-"><br>
<br>
On 06/27/2017 05:35 AM, Adam Heczko wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
Barbican already supports multiple secret storage backends [1] and most likely adding Keycloak's one [2] should be possible.<br>
<br>
[1] <a href="https://docs.openstack.org/project-install-guide/key-manager/draft/barbican-backend.html" rel="noreferrer" target="_blank">https://docs.openstack.org/pro<wbr>ject-install-guide/key-manager<wbr>/draft/barbican-backend.html</a><br>
[2] <a href="https://github.com/jpkrohling/secret-store" rel="noreferrer" target="_blank">https://github.com/jpkrohling/<wbr>secret-store</a><br>
<br></span><span class="gmail-">
On Tue, Jun 27, 2017 at 10:42 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a> <mailto:<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>><wbr>> wrote:<br>
<br>
    Mikhail Fedosin wrote:<br>
    >             Does the above mean you are implementing a share secret storage<br>
    >             solution or that you are going to use an existing solution like<br>
    >             Barbican that does that?<br>
    ><br>
    >         Sectets is a plugin for Glare we developed for Nokia CloudBand<br>
    >         platform,   and they just decided to opensource it. It doesn't<br>
    >         use Barbican, technically it is oslo.versionedobjects class.<br>
    ><br>
    >     Sorry to hear that you opted not to use Barbican.<br>
    ><br>
    > I think it's only because Keycloak integration is required by Nokia's<br>
    > system and Barbican doesn't support it.<br>
<br>
    Any technical reason why it couldn't be added to Barbican ? Any chance<br>
    Keycloak integration could be added as a Castellan backend ? Secrets<br>
    management is really one of those things that should *not* be reinvented<br>
    in every project. It is easier to get wrong than people think, and you<br>
    end up having to do security audits on 10 repositories instead of one.<br>
<br>
    --<br>
    Thierry Carrez (ttx)<br>
<br>
    ______________________________<wbr>______________________________<wbr>______________<br>
    OpenStack Development Mailing List (not for usage questions)<br>
    Unsubscribe:<br>
    <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></span>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><span class="gmail-"><br>
    <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><br>
<br>
<br>
<br>
<br>
-- <br>
Adam Heczko<br>
Security Engineer @ Mirantis Inc.<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>