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 <na...@ntti3.com>: > Hi folks > >> Clint > Thanks, things get clear for me now :) > > > > > > 2014-05-01 13:21 GMT-07:00 John Wood <john.w...@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 [cl...@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 <cl...@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.cl...@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:na...@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.r...@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" <na...@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 >>> >> >> <mest...@noironetworks.com>: >>> >> >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno <na...@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 <cl...@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 >>> >> >> <mest...@noironetworks.com>: >>> >> >> >>>>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno >>> >> >> <na...@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@lists.openstack.org >>> >> >> >>>>> >>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >>>> >>> >> >> >>>> _______________________________________________ >>> >> >> >>>> OpenStack-dev mailing list >>> >> >> >>>> OpenStack-dev@lists.openstack.org >>> >> >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >>> >>> >> >> >>> _______________________________________________ >>> >> >> >>> OpenStack-dev mailing list >>> >> >> >>> OpenStack-dev@lists.openstack.org >>> >> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >>> >> >> >>_______________________________________________ >>> >> >> >>OpenStack-dev mailing list >>> >> >> >>OpenStack-dev@lists.openstack.org >>> >> >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> > >>> >> >> > _______________________________________________ >>> >> >> > OpenStack-dev mailing list >>> >> >> > OpenStack-dev@lists.openstack.org >>> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> > >>> >> >> >>> >> >> _______________________________________________ >>> >> >> OpenStack-dev mailing list >>> >> >> OpenStack-dev@lists.openstack.org >>> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> > >>> >> > _______________________________________________ >>> >> > OpenStack-dev mailing list >>> >> > OpenStack-dev@lists.openstack.org >>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> > >>> >> >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
