Open Stack

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