Open Stack

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.

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.

On 31/08/18 12:02 PM, Adrian Turjak wrote:
>
> 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
>
> __________________________________________________________________________
> 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/51dcfb94/attachment.html>