On Thu, May 29, 2014 at 6:57 AM, Nachi Ueno 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.
Currently We are running havana branch
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>> From: Clint Byrum [cl...@fewbar.com]
>>> Sent: Thursday, May 01, 2014 2:22 PM
>>> To: openstack-dev
>>> Subject: Re:
[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
;
> 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
-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..
> an
nst
> >> > filesystem disk-residency issues.
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Nachi Ueno [mailto:na...@ntti3.com]
> >> >> Sent: 01 May 2014 17:36
> >> >> To: OpenStack Develo
tem 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)
>> >
gt; 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: OpenSt
: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 ke
dency 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
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 :
> Zang mentioned that part of the issue is that the private key has to be
> stored in the OpenVPN config file. If the
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 t
> 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 :
> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno wrote:
>> Hi Clint
>>
>> Thank you for your suggestion. Your
On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno 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
As the PTL for Barbican, I¹m happy to discuss this more here or at the
Summit.
Not sure if this is an option, but could you store the entire OpenVPN
config file in Barbican rather than just the key? Not sure if you are
generating those on demand or not, but we¹ve had several teams inside
Rackspac
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?
> Zang
Could you join the discussion?
2014-04-29 15:48 GMT-07:00 Clint Byrum :
> Excerpts from Nachi Ueno's message of 2014-04-29 10
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 :
> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote:
> >> Hi Zang
> >>
> >> Thank you for your contribution on this!
> >> The private key management is what I want to discus
On Tue, Apr 29, 2014 at 12:58 PM, Nachi Ueno wrote:
> Hi Kyle
>
> 2014-04-29 10:52 GMT-07:00 Kyle Mestery :
>> On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno wrote:
>>> Hi Zang
>>>
>>> Thank you for your contribution on this!
>>> The private key management is what I want to discuss in the summit.
>
Hi Kyle
2014-04-29 10:52 GMT-07:00 Kyle Mestery :
> On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno 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
On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno 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
Hi Zang
Thank you for your contribution on this!
The private key management is what I want to discuss in the summit.
[1] We are depending DB security, anyway
When we get stolen the private key in the DB, it means we are also
stolen ID/PW for DB.
If we stolen the key, even if we keep the private k
21 matches
Mail list logo
