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