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
