scenario, the
> database replication (sync. or async.) capability could be leveraged.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
> From: Lance Bragstad [mailto:lbrags...@gmail.com]
> Sent: Tuesday, August 04, 2015 10:56 PM
> To: OpenStack Development Mailing List (not
[mailto:lbrags...@gmail.com]
Sent: Wednesday, August 05, 2015 9:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys
On Wed, Aug 5, 2015 at 2:38 AM, Adam Heczko
mailto:ahec...@mirantis.com>> wrote:
>
>> Best Regards
>>
>> Chaoyi Huang ( Joe Huang )
>>
>>
>>
>> *From:* Lance Bragstad [mailto:lbrags...@gmail.com]
>> *Sent:* Tuesday, August 04, 2015 10:56 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subje
PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for
> Fernet keys
>
>
>
>
>
> On Tue, Aug 4, 2015 at 9:28 AM, Boris Bobrov wrote:
>
> On Tuesday 04 August 2015 08:06:21 Lance
leveraged.
Best Regards
Chaoyi Huang ( Joe Huang )
From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: Tuesday, August 04, 2015 10:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys
On Tue, Aug 4
On Tue, Aug 4, 2015 at 9:28 AM, Boris Bobrov wrote:
> On Tuesday 04 August 2015 08:06:21 Lance Bragstad wrote:
> > On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov
> wrote:
> > > On Monday 03 August 2015 21:05:00 David Stanek wrote:
> > > > On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov
> > >
> > > w
On Tuesday 04 August 2015 08:06:21 Lance Bragstad wrote:
> On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov wrote:
> > On Monday 03 August 2015 21:05:00 David Stanek wrote:
> > > On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov
> >
> > wrote:
> > > > Also, come on, does http://paste.openstack.org/show/4
On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov wrote:
> On Monday 03 August 2015 21:05:00 David Stanek wrote:
>
> > On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov
> wrote:
>
> > > On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum wrote:
>
> > > > This too is overly complex and will cause failures. If you
On Monday 03 August 2015 21:05:00 David Stanek wrote:
> On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov
wrote:
> > On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum
wrote:
> > > This too is overly complex and will cause failures. If you replace key
> > > 0,
> > >
> > > you will stop validating tokens t
> On 3 Aug 2015, at 8:02 pm, Sergii Golovatiuk wrote:
>
> Hi,
>
> I agree with Bogdan that key rotation procedure should be part of HA solution.
These things don’t usually have to be an either/or situation.
Why not create one script that does the work and can be called manually if
desired but
On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov wrote:
> On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum wrote:
>
> > This too is overly complex and will cause failures. If you replace key 0,
>
> > you will stop validating tokens that were encrypted with the old key 0.
>
>
>
> No. Key 0 is replaced aft
Folks
As Sergii G. already pointed out if you want this solution to work in
production, you should provide common ways of synchronization between
different processing entities. Otherwise your "very simple one-script
solution" will be prone to errors such as race conditions and others. You
need to
On Mon, Aug 3, 2015 at 7:03 AM, David Stanek wrote:
>
> On Mon, Aug 3, 2015 at 7:14 AM, Davanum Srinivas
> wrote:
>
>> agree. "Native HA solution" was already ruled out in several email
>> threads by keystone cores already (if i remember right). This is a
>> devops issue and should be handled as
Fine, then this simple bash based solution proposed by Boris [1] LGTM and
is not over thinked.
Maybe add kind of md5 or sha1 checksum functionality to confirm if keys
were rotated correctly and are in sync.
[1] http://paste.openstack.org/show/406674/
Regards,
Adam
On Mon, Aug 3, 2015 at 2:03 PM
On Mon, Aug 3, 2015 at 7:14 AM, Davanum Srinivas wrote:
> agree. "Native HA solution" was already ruled out in several email
> threads by keystone cores already (if i remember right). This is a
> devops issue and should be handled as such was the feedback.
>
I'm sure you are right. I'm not sure
> On Aug 3, 2015, at 21:14, Davanum Srinivas wrote:
>
> agree. "Native HA solution" was already ruled out in several email
> threads by keystone cores already (if i remember right). This is a
> devops issue and should be handled as such was the feedback.
>
Correct. This is generally considere
agree. "Native HA solution" was already ruled out in several email
threads by keystone cores already (if i remember right). This is a
devops issue and should be handled as such was the feedback.
Thanks,
-- dims
On Mon, Aug 3, 2015 at 7:03 AM, Sergii Golovatiuk
wrote:
> Hi,
>
> --
> Best regards,
Hi,
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Mon, Aug 3, 2015 at 12:44 PM, Adam Heczko wrote:
> Hi folks, we are discussing operations on sensitive data.
> May I ask you what security controls Pacemaker provides?
>
Pacemaker doesn't exchange any security information.
Hi folks, we are discussing operations on sensitive data.
May I ask you what security controls Pacemaker provides?
How we could audit its operations and data it is accessing?
The same question arises when discussing native Keystone solution.
>From the security perspective, reduction of attack surfa
Hi,
I agree with Bogdan that key rotation procedure should be part of HA
solution. If you make a simple script then this script will be a single
point of failure. It requires operator's attention so it may lead to human
errors also. Adding monitoring around it or expiration time is not a
solution
Glad to see you weighed in on this. -d
On Sat, Aug 1, 2015 at 3:50 PM, Matt Fischer wrote:
> Agree that you guys are way over thinking this. You don't need to rotate
> keys at exactly the same time, we do it in within a one or two hours
> typically based on how our regions are setup. We do it wi
On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum wrote:
> This too is overly complex and will cause failures. If you replace key 0,
> you will stop validating tokens that were encrypted with the old key 0.
No. Key 0 is replaced after rotation.
Also, come on, does http://paste.openstack.org/show/40667
Agree that you guys are way over thinking this. You don't need to rotate
keys at exactly the same time, we do it in within a one or two hours
typically based on how our regions are setup. We do it with puppet, puppet
runs on one keystone node at a time and drops the keys into place. The
actual rota
Excerpts from Boris Bobrov's message of 2015-08-01 14:18:21 -0700:
> On Saturday 01 August 2015 16:27:17 bdobre...@mirantis.com wrote:
> > I suggest to use pacemaker multistate clone resource to rotate and
> rsync
> > fernet tokens from local directories across cluster nodes. The resource
> > prot
On Saturday 01 August 2015 16:27:17 bdobre...@mirantis.com wrote:
> I suggest to use pacemaker multistate clone resource to rotate and
rsync
> fernet tokens from local directories across cluster nodes. The resource
> prototype is described here
> https://etherpad.openstack.org/p/fernet_tokens_pace
Meta: Bogdan, please do try to get your email client to reply with references
to the thread, so it doesn't create a new thread.
Excerpts from bdobrelia's message of 2015-08-01 09:27:17 -0700:
> I suggest to use pacemaker multistate clone resource to rotate and rsync
> fernet tokens from local dir
I suggest to use pacemaker multistate clone resource to rotate and rsync fernet
tokens from local directories across cluster nodes. The resource prototype is
described here https://etherpad.openstack.org/p/fernet_tokens_pacemaker
Pros: Pacemaker will care about CAP/split-brain stuff for us, we ju
Matt Fischer also discusses key rotation here:
http://www.mattfischer.com/blog/?p=648
And here:
http://www.mattfischer.com/blog/?p=665
On Mon, Jul 27, 2015 at 2:30 PM, Dolph Mathews
wrote:
>
>
> On Mon, Jul 27, 2015 at 2:03 PM, Clint Byrum wrote:
>
>> Excerpts from Dolph Mathews's messag
On Mon, Jul 27, 2015 at 2:03 PM, Clint Byrum 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 wrote:
> >
> > > Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700:
> > > > Greetings!
> > > >
> > > > I
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 wrote:
>
> > Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700:
> > > Greetings!
> > >
> > > I'd like to discuss pro's and contra's of having Fernet encryption k
On Mon, Jul 27, 2015 at 1:31 PM, Clint Byrum wrote:
> Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700:
> > Greetings!
> >
> > I'd like to discuss pro's and contra's of having Fernet encryption keys
> > stored in a database backend.
> > The idea itself emerged during discuss
-dev] [Keystone][Fernet] HA SQL backend for Fernet keys
Although using a node's *local* filesystem requires external configuration
management to manage the distribution of rotated keys, it's always available,
easy to secure, and can be updated atomically per node. Note that Fernet&#
Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700:
> Greetings!
>
> I'd like to discuss pro's and contra's of having Fernet encryption keys
> stored in a database backend.
> The idea itself emerged during discussion about synchronizing rotated keys
> in HA environment.
> Now F
Although using a node's *local* filesystem requires external configuration
management to manage the distribution of rotated keys, it's always
available, easy to secure, and can be updated atomically per node. Note
that Fernet's rotation strategy uses a staged key that can be distributed
to all node
Greetings!
I'd like to discuss pro's and contra's of having Fernet encryption keys
stored in a database backend.
The idea itself emerged during discussion about synchronizing rotated keys
in HA environment.
Now Fernet keys are stored in the filesystem that has some availability
issues in unstable
35 matches
Mail list logo
