Open Stack

Hi folks

> Clint
Thanks, things get clear for me now :)





2014-05-01 13:21 GMT-07:00 John Wood <john.wood at rackspace.com>:
> I was going to bring up Postern [1] as well, Clint. Unfortunately not much work has been done on it though.
>
> [1] https://github.com/cloudkeep/postern
>
> Thanks,
> John
>
>
>
> ________________________________________
> From: Clint Byrum [clint at fewbar.com]
> Sent: Thursday, May 01, 2014 2:22 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
>
> Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700:
>> Ah I got it now!
>> so even if we get stolen HDD, we can keep password safe.
>>
>> However, I'm still not sure why this is more secure..
>> anyway, the ID/PW to access barbican will be written in neutron.conf, right?
>>
>
> Yes. However, you can surround the secret in policies. You'll have an
> audit trail of when and where it was accessed, and you can even restrict
> access, so that out of band you have to open up access with barbican.
>
> So while the server may have access, that access is now audited and
> limited by policy, instead of just being dependent on the security
> measures you can take to protect a file.
>
>> Furthermore,  ID/PW for mysql will be written in conf file..
>> so if we can't trust unix file system protection, there is no security
>> in OpenStack.
>
> The ID/PW for mysql only grants you access to mysql for as long as that
> id/pw are enabled for access. However, the encryption keys for OpenVPN
> will grant any passive listener access for as long as they keep any
> sniffed traffic. They'll also grant an attacker the ability to MITM
> traffic between peers.
>
> So when an encryption key has been accessed, from where, etc, is quite
> a bit more crucial than knowing when a username/password combo have
> been accessed.
>
> Producing a trustworthy audit log for access to /etc/neutron/neutron.conf
> is a lot harder than producing an audit log for a REST API.
>
> So it isn't so much that file system permissions aren't enough, it is
> that file system observability is expensive.
>
> Note that at some point there was a POC to have a FUSE driver backed by
> Barbican called 'Postern' I think. That would make these discussions a
> lot simpler. :)
>
>>
>> 2014-05-01 10:31 GMT-07:00 Clint Byrum <clint at fewbar.com>:
>> > I think you'd do something like this (Note that I don't know off the top
>> > of my head the barbican CLI or openvpn cli switches... just
>> > pseudo-code):
>> >
>> > oconf=$(mktemp -d /tmp/openvpnconfig.XXXXXX)
>> > mount -o tmpfs $oconf size=1M
>> > barbican get my-secret-openvpn-conf > $oconf/foo.conf
>> > openvpn --config-dir $oconf foo --daemonize
>> > umount $oconf
>> > rmdir $oconf
>> >
>> > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700:
>> >> Hi Robert
>> >>
>> >> Thank you for your suggestion.
>> >> so your suggestion is let OpenVPN process download key to memory
>> >> directly from Babican?
>> >>
>> >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham <robert.clark at hp.com>:
>> >> > Excuse me interrupting but couldn't you treat the key as largely
>> >> > ephemeral, pull it down from Barbican, start the OpenVPN process and
>> >> > then purge the key?  It would of course still be resident in the memory
>> >> > of the OpenVPN process but should otherwise be protected against
>> >> > filesystem disk-residency issues.
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Nachi Ueno [mailto:nachi at ntti3.com]
>> >> >> Sent: 01 May 2014 17:36
>> >> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
>> >> >>
>> >> >> Hi Jarret
>> >> >>
>> >> >> IMO, Zang point is the issue saving plain private key in the
>> >> > filesystem for
>> >> >> OpenVPN.
>> >> >> Isn't this same even if we use Barbican?
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim <jarret.raim at rackspace.com>:
>> >> >> > Zang mentioned that part of the issue is that the private key has to
>> >> >> > be stored in the OpenVPN config file. If the config files are
>> >> >> > generated and can be stored, then storing the whole config file in
>> >> >> > Barbican protects the private key (and any other settings) without
>> >> >> > having to try to deliver the key to the OpenVPN endpoint in some
>> >> > non-
>> >> >> standard way.
>> >> >> >
>> >> >> >
>> >> >> > Jarret
>> >> >> >
>> >> >> > On 4/30/14, 6:08 PM, "Nachi Ueno" <nachi at ntti3.com> wrote:
>> >> >> >
>> >> >> >>> Jarret
>> >> >> >>
>> >> >> >>Thanks!
>> >> >> >>Currently, the config will be generated on demand by the agent.
>> >> >> >>What's merit storing entire config in the Barbican?
>> >> >> >>
>> >> >> >>> Kyle
>> >> >> >>Thanks!
>> >> >> >>
>> >> >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery
>> >> >> <mestery at noironetworks.com>:
>> >> >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno <nachi at ntti3.com>
>> >> >> wrote:
>> >> >> >>>> Hi Clint
>> >> >> >>>>
>> >> >> >>>> Thank you for your suggestion. Your point get taken :)
>> >> >> >>>>
>> >> >> >>>>> Kyle
>> >> >> >>>> This is also a same discussion for LBaaS Can we discuss this in
>> >> >> >>>> advanced service meeting?
>> >> >> >>>>
>> >> >> >>> Yes! I think we should definitely discuss this in the advanced
>> >> >> >>> services meeting today. I've added it to the agenda [1].
>> >> >> >>>
>> >> >> >>> Thanks,
>> >> >> >>> Kyle
>> >> >> >>>
>> >> >> >>> [1]
>> >> >> >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f
>> >> >> or_
>> >> >> >>>next
>> >> >> >>>_meeting
>> >> >> >>>
>> >> >> >>>>> Zang
>> >> >> >>>> Could you join the discussion?
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum <clint at fewbar.com>:
>> >> >> >>>>> Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700:
>> >> >> >>>>>> Hi Kyle
>> >> >> >>>>>>
>> >> >> >>>>>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery
>> >> >> <mestery at noironetworks.com>:
>> >> >> >>>>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno
>> >> >> <nachi at ntti3.com>
>> >> >> >>>>>>wrote:
>> >> >> >>>>>> >> Hi Zang
>> >> >> >>>>>> >>
>> >> >> >>>>>> >> Thank you for your contribution on this!
>> >> >> >>>>>> >> The private key management is what I want to discuss in the
>> >> >> >>>>>>summit.
>> >> >> >>>>>> >>
>> >> >> >>>>>> > Has the idea of using Barbican been discussed before? There
>> >> > are
>> >> >> >>>>>>many
>> >> >> >>>>>> > reasons why using Barbican for this may be better than
>> >> >> >>>>>> > developing
>> >> >> >>>>>>key
>> >> >> >>>>>> > management ourselves.
>> >> >> >>>>>>
>> >> >> >>>>>> No, however I'm +1 for using Barbican. Let's discuss this in
>> >> >> >>>>>> certificate management topic in advanced service session.
>> >> >> >>>>>>
>> >> >> >>>>>
>> >> >> >>>>> Just a suggestion: Don't defer that until the summit. Sounds
>> >> > like
>> >> >> >>>>>you've  already got some consensus, so you don't need the summit
>> >> >> >>>>>just to rubber  stamp it. I suggest discussing as much as you can
>> >> >> >>>>>right now on the mailing  list, and using the time at the summit
>> >> > to
>> >> >> >>>>>resolve any complicated issues  including any "a or b" things
>> >> > that
>> >> >> >>>>>need crowd-sourced idea making. You  can also use the summit time
>> >> >> >>>>>to communicate your requirements to the  Barbican developers.
>> >> >> >>>>>
>> >> >> >>>>> Point is: just because you'll have face time, doesn't mean you
>> >> >> >>>>> should use it for what can be done via the mailing list.
>> >> >> >>>>>
>> >> >> >>>>> _______________________________________________
>> >> >> >>>>> OpenStack-dev mailing list
>> >> >> >>>>> OpenStack-dev at lists.openstack.org
>> >> >> >>>>>
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >> >>>>
>> >> >> >>>> _______________________________________________
>> >> >> >>>> OpenStack-dev mailing list
>> >> >> >>>> OpenStack-dev at lists.openstack.org
>> >> >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> OpenStack-dev mailing list
>> >> >> >>> OpenStack-dev at lists.openstack.org
>> >> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >> >>
>> >> >> >>_______________________________________________
>> >> >> >>OpenStack-dev mailing list
>> >> >> >>OpenStack-dev at lists.openstack.org
>> >> >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > OpenStack-dev mailing list
>> >> >> > OpenStack-dev at lists.openstack.org
>> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >> >
>> >> >>
>> >> >> _______________________________________________
>> >> >> OpenStack-dev mailing list
>> >> >> OpenStack-dev at lists.openstack.org
>> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >> > _______________________________________________
>> >> > OpenStack-dev mailing list
>> >> > OpenStack-dev at lists.openstack.org
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >>
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev