[openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

Adrian Turjak adriant at catalyst.net.nz
Fri Aug 31 00:02:08 UTC 2018


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).

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.

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.

On 31/08/18 1:50 AM, Lance Bragstad wrote:
> 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.
>
> [0] https://review.openstack.org/#/c/311268/
> [1] https://review.openstack.org/#/c/363065/
> [2] https://review.openstack.org/#/c/439194/
>
> On Thu, Aug 30, 2018 at 5:02 AM Juan Antonio Osorio Robles
> <jaosorior at redhat.com <mailto:jaosorior at redhat.com>> wrote:
>
>     FWIW, instead of barbican, castellan could be used as a key manager.
>
>
>     On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>>
>>
>>     On 30/08/18 6:29 AM, Lance Bragstad wrote:
>>>
>>>         Is that what is being described here ? 
>>>         https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>>
>>>
>>>     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.
>>>      
>>
>>     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.
>>
>>     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?
>>
>>
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20180831/97a26fb1/attachment.html>


More information about the OpenStack-dev mailing list