Open Stack

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