<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Actually now that I think about it, another problem is that (at
least in our case) Keystone is really a cluster wide service
present across regions, so if it was to use Barbican (or Vault for
that matter) then the secret store service would too need to be
cluster wide and across all regions.<br>
<br>
Our current plan for our deployment of Barbican is per region. Is
that the norm? Because if so, then it kind of means using it for
Keystone becomes less useful.<br>
</p>
<div class="moz-cite-prefix">On 31/08/18 12:02 PM, Adrian Turjak
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9afb81e7-2727-cb49-417a-46b6e0ae3110@catalyst.net.nz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Oh I was literally just thinking about the 'credential' type
key value items we store in the Keystone DB. Rather than storing
them in the Keystone db and worrying about encryption (and
encryption keys) in Keystone around what is otherwise a
plaintext secret, just offload that to a service specific for
handling those (which Keystone isn't).<br>
<br>
My only really worry then is if tying MFA credential values to
an external service is a great idea as now Keystone and Barbican
have to be alive for auth to occur (plus auth could be
marginally slower). Although by using an external service
security could potentially be enhanced and deployers don't need
to worry about credential encryption key rotation (and
re-encryption of credentials) in Keystone.<br>
</p>
<p>As for fernet keys in Barbican... that that does sound like a
fairly terrifying chicken and egg problem. Although Castellan
with a Vault plugin sounds doable (not tied back to Keystone's
own auth), and could actually be useful for multi-host keystone
deployments since Vault now handles your Key
replication/distribution provided Keystone rotates keys into it.<br>
</p>
<div class="moz-cite-prefix">On 31/08/18 1:50 AM, Lance Bragstad
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE6oFcFGv+sxxYPN6i59f5F7H5E6SbSO_ags8-OEK=M92H7_1w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">This topic has surfaced intermittently ever since
keystone implemented fernet tokens in Kilo. An initial idea
was written down shortly afterwords [0], then we targeted it
to Ocata [1], and removed from the backlog around the Pike
timeframe [2]. The commit message of [2] includes meeting
links. The discussion usually tripped attempting to abstract
enough of the details about rotation and setup of keys to work
in all cases.
<div><br>
</div>
<div>[0] <a href="https://review.openstack.org/#/c/311268/"
moz-do-not-send="true">https://review.openstack.org/#/c/311268/</a></div>
<div>[1] <a href="https://review.openstack.org/#/c/363065/"
moz-do-not-send="true">https://review.openstack.org/#/c/363065/</a></div>
<div>[2] <a href="https://review.openstack.org/#/c/439194/"
moz-do-not-send="true">https://review.openstack.org/#/c/439194/</a><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Aug 30, 2018 at 5:02 AM Juan
Antonio Osorio Robles <<a
href="mailto:jaosorior@redhat.com"
moz-do-not-send="true">jaosorior@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
 0.8ex;border-left:1px solid

rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>FWIW, instead of barbican, castellan could be used
as a key manager.<br>
</p>
<br>
<div class="gmail-m_244733796970506849moz-cite-prefix">On
08/30/2018 12:23 PM, Adrian Turjak wrote:<br>
</div>
<blockquote type="cite">
<div class="gmail-m_244733796970506849moz-text-html"
lang="x-unicode">
<p><br>
</p>
<div
class="gmail-m_244733796970506849moz-cite-prefix">On
30/08/18 6:29 AM, Lance Bragstad wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px

0.8ex;border-left:1px solid

rgb(204,204,204);padding-left:1ex">
<div bgcolor="white" lang="EN-US">
<div
class="gmail-m_244733796970506849m_329163095983434052WordSection1">
<p class="MsoNormal"><span
style="font-size:11pt">Is that
what is being described here ? <a
href="https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html"
target="_blank"
moz-do-not-send="true">
https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html</a></span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This is a separate mechanism for
storing secrets, not necessarily passwords
(although I agree the term credentials
automatically makes people assume
passwords). This is used if consuming
keystone's native MFA implementation. For
example, storing a shared secret between
the user and keystone that is provided as
a additional authentication method along
with a username and password combination.</div>
<div> </div>
</div>
</div>
</blockquote>
<p>Is there any interest or plans to potentially
allow Keystone's credential store to use
Barbican as a storage provider? Encryption
already is better than nothing, but if you
already have (or will be deploying) a proper
secret store with a hardware backend (or at
least hardware stored encryption keys) then it
might make sense to throw that in Barbican.<br>
<br>
Or is this also too much of a chicken/egg
problem? How safe is it to rely on Barbican
availability for MFA secrets and auth?<br>
</p>
</div>
<br>
<fieldset
class="gmail-m_244733796970506849mimeAttachmentHeader"></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="gmail-m_244733796970506849moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank" moz-do-not-send="true">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="gmail-m_244733796970506849moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
__________________________________________________________________________<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"
moz-do-not-send="true">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" moz-do-not-send="true">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
</body>
</html>