[openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys
dolph.mathews at gmail.com
Mon Jul 27 19:33:31 UTC 2015
Matt Fischer also discusses key rotation here:
On Mon, Jul 27, 2015 at 2:30 PM, Dolph Mathews <dolph.mathews at gmail.com>
> On Mon, Jul 27, 2015 at 2:03 PM, Clint Byrum <clint at fewbar.com> wrote:
>> Excerpts from Dolph Mathews's message of 2015-07-27 11:48:12 -0700:
>> > On Mon, Jul 27, 2015 at 1:31 PM, Clint Byrum <clint at fewbar.com> wrote:
>> > > Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34
>> > > > Greetings!
>> > > >
>> > > > I'd like to discuss pro's and contra's of having Fernet encryption
>> > > > stored in a database backend.
>> > > > The idea itself emerged during discussion about synchronizing
>> > > keys
>> > > > in HA environment.
>> > > > Now Fernet keys are stored in the filesystem that has some
>> > > > issues in unstable cluster.
>> > > > OTOH, making SQL highly available is considered easier than that
>> for a
>> > > > filesystem.
>> > > >
>> > >
>> > > I don't think HA is the root of the problem here. The problem is
>> > > synchronization. If I have 3 keystone servers (n+1), and I rotate
>> keys on
>> > > them, I must very carefully restart them all at the exact right time
>> > > make sure one of them doesn't issue a token which will not be
>> > > on another. This is quite a real possibility because the validation
>> > > will not come from the user, but from the service, so it's not like we
>> > > can use simple persistence rules. One would need a layer 7 capable
>> > > balancer that can find the token ID and make sure it goes back to the
>> > > server that issued it.
>> > >
>> > This is not true (or if it is, I'd love see a bug report).
>> > fernet_rotate uses a three phase rotation strategy (staged -> primary ->
>> > secondary) that allows you to distribute a staged key (used only for
>> > validation) throughout your cluster before it becomes a primary key
>> > for token creation and validation) anywhere. Secondary keys are only
>> > for token validation.
>> > All you have to do is atomically replace the fernet key directory with a
>> > new key set.
>> > You also don't have to restart keystone for it to pickup new keys
>> > onto the filesystem beneath it.
>> That's great news! Is this documented anywhere? I dug through the
>> operators guides, security guide, install guide, etc. Nothing described
>> this dance, which is impressive and should be written down!
> (BTW, your original assumption would normally have been an accurate one!)
> I don't believe it's documented in any of those places, yet. The best
> explanation of the three phases in tree I'm aware of is probably this
> (which isn't particularly accessible..):
> Lance Bragstad and I also gave a small presentation at the Vancouver
> summit on the behavior and he mentions the same on one of his blog posts:
>> I even tried to discern how it worked from the code but it actually
>> looks like it does not work the way you describe on casual investigation.
> I don't blame you! I'll work to improve the user-facing docs on the topic.
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev