Open Stack

Just chiming in with a side-note.

I always liked the idea of Postern for things like this though the crypto
geek in me always worries about making key retrieval too easy for
developers, bad things happen down that road.

The OSSG can help with overall secure design and would be happy to consult
if you¹d like. We have a separate list for security specific stuff but I
think a conversation on -dev would make more sense, just tag it [OSSG] :)

-Rob


On 28/05/2014 23:57, "Nachi Ueno" <nachi at ntti3.com> wrote:

>Hi Zang
>
>Since, SSL-VPN for Juno bp is approved in neturon-spec,
>I would like to restart this work.
>Could you share your code if it is possible?
>Also, Let's discuss how we can collaborate in here.
>
>Best
>Nachi
>
>
>2014-05-01 14:40 GMT-07:00 Nachi Ueno <nachi at ntti3.com>:
>> 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
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev