cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <paul.an...@shapeblue.com>
Subject RE: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault
Date Wed, 04 Apr 2018 16:29:25 GMT
You guys should speak to Rohit about the CA framework.  CloudStack can manage certificates
now, including creating them itself and acting as a root CA.




Kind regards,

Paul Angus

paul.angus@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-----Original Message-----
From: Rafael Weingärtner <rafaelweingartner@gmail.com> 
Sent: 04 April 2018 16:51
To: dev <dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Thanks for sharing the details. Now I have a better perspective of the proposal.It is an interesting
integration of CloudStack VPN service with Vault PKI feature.

On Wed, Apr 4, 2018 at 12:38 PM, Khosrow Moossavi <kmoossavi@cloudops.com>
wrote:

> One of the things Vault does is essentially one of the thing Let's 
> Encrypt does, acting as CA and generating/signing certificates.
>
> From the Vault website itself:
>
> "HashiCorp Vault secures, stores, and tightly controls access to 
> tokens, passwords, certificates, API keys, and other secrets in modern 
> computing. Vault handles leasing, key revocation, key rolling, and 
> auditing. Through a unified API, users can access an encrypted 
> Key/Value store and network encryption-as-a-service, or generate AWS 
> IAM/STS credentials, SQL/NoSQL databases, X.509 certificates, SSH 
> credentials, and more."
>
> In our case we are going to use Vault as PKI backend engine, to act as 
> Root CA, sign certificates, handle CRL (Certificate Revocation List), 
> etc.
> Technically we can
> do these with Let's Encrypt, but I haven't started exploring the 
> possibilities or potential limitation. Using external services (such 
> as Let's Encrypt) or going forward with Bring You Own Certificate 
> model would be for future, it they ever made sense to do.
>
>
>
> On Wed, Apr 4, 2018 at 11:20 AM, Rafael Weingärtner < 
> rafaelweingartner@gmail.com> wrote:
>
> > Got it. Thanks for the explanations.
> > There is one other thing I do not understand. This Vault thing that 
> > you mention, how does it work? Is it similar to let's encrypt?
> >
> > On Wed, Apr 4, 2018 at 12:15 PM, Khosrow Moossavi <
> kmoossavi@cloudops.com>
> > wrote:
> >
> > > On Wed, Apr 4, 2018 at 10:36 AM, Rafael Weingärtner < 
> > > rafaelweingartner@gmail.com> wrote:
> > >
> > > > So, you need a certificate that is signed by the CA that is used 
> > > > by
> the
> > > VPN
> > > > service. Is that it?
> > > >
> > > >
> > > Correct, a self signed "server certificate" against CA, to be 
> > > installed directly on VR.
> > >
> > >
> > > >
> > > > It has been a while that I do not configure these VPN systems; 
> > > > do you
> > > need
> > > > access to the private key of the CA? Or, does the program simply
> > validate
> > > > the user (VPN client) certificate to see if it is issued by a
> specific
> > > CA?
> > > > I believe it also needs the public key of the user to execute 
> > > > the
> > > handshake
> > > > and create the connection.
> > > >
> > > >
> > > >
> > > No, end user only needs to have Root CA at hand, to *trust* it. 
> > > Both
> the
> > > "Server
> > > Certificate" and "Server Private Key" are sensitive information 
> > > and
> only
> > > exist  on
> > > VR.
> > >
> > > User then can go ahead and install the Root CA on their local 
> > > machine
> and
> > > open
> > > up VPN connection with strongSwan client of the correspondning OS
> they're
> > > on
> > > import the Root CA, and their credential (EAP on VPN side), and 
> > > that's
> > it.
> > >
> > >
> > > >
> > > >
> > > > On Wed, Apr 4, 2018 at 11:22 AM, Khosrow Moossavi <
> > > kmoossavi@cloudops.com>
> > > > wrote:
> > > >
> > > > > Rafael,
> > > > >
> > > > > We cannot use SshKeyPair functionality because the proposed 
> > > > > VPN implementation does need a signed certificate and not a 
> > > > > ssh key pair. The process
> is
> > > as
> > > > > follow:
> > > > >
> > > > > 1) generate root CA (if doesn't exist)
> > > > > 2) generate bunch of intermediate steps (config urls, CRLs, 
> > > > > role
> > name,
> > > > ...)
> > > > > [I'm not going
> > > > > in detail now, here, for simplicity]
> > > > > 3) self sign a certificate against the root CA (regenerate 
> > > > > every
> time
> > > > start
> > > > > VPN command
> > > > > executed)
> > > > >
> > > > > This will produce:
> > > > >
> > > > > 1) Root CA cert (one per domain in cloudstack)
> > > > > 2) Server cert (one per VR)
> > > > > 3) Server private key (one per VR)
> > > > >
> > > > > Then all the above will be pushed to the said VR we want to 
> > > > > start
> VPN
> > > on,
> > > > > and start
> > > > > ipsec service on it (with extra configuration - which will be
> > available
> > > > in
> > > > > codebase) and
> > > > > finally present Root CA for user to download and install on 
> > > > > their
> > local
> > > > > machine to be
> > > > > able to "trust" VR they are VPNing to.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Apr 4, 2018 at 6:19 AM, Rafael Weingärtner < 
> > > > > rafaelweingartner@gmail.com> wrote:
> > > > >
> > > > > > Khosrow thanks for the interesting feature. You mention two
> > possible
> > > > > > methods to manage certificates; one using the CA framework,

> > > > > > and
> > other
> > > > > using
> > > > > > third party such as Vault and Let’s Encrypt.
> > > > > >
> > > > > > Have you considered using the sshKeyPair API methods (is it

> > > > > > part
> of
> > > the
> > > > > CA
> > > > > > framework?)? I mean, users already can generate key pairs 
> > > > > > via
> ACS,
> > > and
> > > > > then
> > > > > > they are presented with the private key. You could simply 
> > > > > > list
> > these
> > > > > > certificates for the user when they want to configure a new
> > > certificate
> > > > > for
> > > > > > a VPN or generate one in runtime using this feature. Reading

> > > > > > your
> > > > feature
> > > > > > proposal I did not understand how you are binding 
> > > > > > certificated
> > with a
> > > > VPN
> > > > > > (are you always generating new ones and simply returning the
> > private
> > > > key
> > > > > to
> > > > > > users?).
> > > > > >
> > > > > > Moreover, as the sshKeyPair methods, I do believe you should

> > > > > > only
> > > > return
> > > > > > the private key once. Therefore, you should not store it in
ACS.
> > > > > >
> > > > > > On Mon, Apr 2, 2018 at 4:36 PM, Khosrow Moossavi <
> > > > kmoossavi@cloudops.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Community
> > > > > > >
> > > > > > > I want to open up a discussion around the new Remote 
> > > > > > > Access VPN implementation on VRs. Currently we have only

> > > > > > > L2TP implementation, which lacks different
> features
> > > > (such
> > > > > as
> > > > > > > verbos logging), so we
> > > > > > > decided to start developing new implementation based on

> > > > > > > IKEv2
> (on
> > > top
> > > > > of
> > > > > > > the existing strongSwan).
> > > > > > >
> > > > > > > We have this feature working locally for over a week now,

> > > > > > > and
> > seems
> > > > to
> > > > > be
> > > > > > > ready for opening up a
> > > > > > > PR on official repo. But before doing so we agreed to open

> > > > > > > up a
> > > > > > discussion
> > > > > > > here first.
> > > > > > >
> > > > > > > The current implementation we use EAP + Public Key for
> > > > authentication,
> > > > > so
> > > > > > > we need to have a PKI
> > > > > > > Engine somewhere. Rather than start re-inventing the wheel

> > > > > > > (and
> > > start
> > > > > > > extending the current CA Framework which was done by 
> > > > > > > Rohit) we decided to delegate this
> > functionality
> > > to
> > > > > > > HashiCorp Vault, which will act as a PKI backend engine

> > > > > > > for Cloudstack.
> > > > > > >
> > > > > > > The way I implemented this specific part of the code, is

> > > > > > > that
> it
> > > can
> > > > > > easily
> > > > > > > be extended/implemented with other concrete classes or

> > > > > > > designs (such as going forward with
> in-house
> > > PKI
> > > > > > > engine, or even use external services such as Let's 
> > > > > > > Encrypt), but at the end of the day we strongly
> > > suggest
> > > > > to
> > > > > > > use Vault, as it is really easy to use.
> > > > > > >
> > > > > > >
> > > > > > > Please find the design document here[1], and share your
> > feedback. I
> > > > > will
> > > > > > > open up a PR -as is- soon to be able to have a source code

> > > > > > > to discuss around it as well.
> > > > > > >
> > > > > > > [1]:
> > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> > > > > > > VPN+Implementation+based+on+IKEv2+backed+by+Vault+as+PKI+
> Engine
> > > > > > >
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Khosrow Moossavi
> > > > > > >
> > > > > > > Cloud Infrastructure Developer
> > > > > > >
> > > > > > > t 514.447.3456
> > > > > > >
> > > > > > > <https://goo.gl/NYZ8KK>
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Rafael Weingärtner
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Rafael Weingärtner
> > > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



--
Rafael Weingärtner
Mime
View raw message