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

[Adrian Turjak]

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
>> mailto:jaosor...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not 

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

[Adrian Turjak]

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
> mailto:jaosor...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lance Bragstad]

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 <
jaosor...@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-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Juan Antonio Osorio Robles]

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adrian Turjak]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lance Bragstad]

On Wed, Aug 29, 2018 at 1:16 PM Waines, Greg 
wrote:

> Makes sense.
>
>
>
> So what is the recommended upstream approach for securely storing user
> passwords in keystone ?
>

Keystone will hash passwords before persisting them in their own table.
Encrypted passwords are never stored.


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


>
>
>
>
> Greg.
>
>
>
>
>
> *From: *Juan Antonio Osorio Robles 
> *Reply-To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Date: *Wednesday, August 29, 2018 at 2:00 PM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [keystone] [barbican] Keystone's use of
> Barbican ?
>
>
>
> This is not the case. Barbican requires users and systems that use it to
> use keystone for authentication. So keystone can't use Barbican for this.
> Chicken and egg problem.
>
>
>
> On 08/29/2018 08:08 PM, Waines, Greg wrote:
>
> My understanding is that Keystone can be configured to use Barbican to
> securely store user passwords.
>
> Is this true ?
>
>
>
> If yes, is this the standard / recommended / upstream way to securely
> store Keystone user passwords ?
>
>
>
> If yes, I can’t find any descriptions of this is configured ?
>
> Can someone provide some pointers ?
>
>
>
> Greg.
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Waines, Greg]

Makes sense.

So what is the recommended upstream approach for securely storing user 
passwords in keystone ?

Is that what is being described here ?  
https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html


Greg.


From: Juan Antonio Osorio Robles 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Wednesday, August 29, 2018 at 2:00 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?


This is not the case. Barbican requires users and systems that use it to use 
keystone for authentication. So keystone can't use Barbican for this. Chicken 
and egg problem.

On 08/29/2018 08:08 PM, Waines, Greg wrote:
My understanding is that Keystone can be configured to use Barbican to securely 
store user passwords.
Is this true ?

If yes, is this the standard / recommended / upstream way to securely store 
Keystone user passwords ?

If yes, I can’t find any descriptions of this is configured ?
Can someone provide some pointers ?

Greg.




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Juan Antonio Osorio Robles]

This is not the case. Barbican requires users and systems that use it to
use keystone for authentication. So keystone can't use Barbican for
this. Chicken and egg problem.


On 08/29/2018 08:08 PM, Waines, Greg wrote:
>
> My understanding is that Keystone can be configured to use Barbican to
> securely store user passwords.
>
> Is this true ?
>
>  
>
> If yes, is this the standard / recommended / upstream way to securely
> store Keystone user passwords ?
>
>  
>
> If yes, I can’t find any descriptions of this is configured ?
>
> Can someone provide some pointers ?
>
>  
>
> Greg.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev