You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by Khosrow Moossavi <km...@cloudops.com> on 2018/04/02 19:36:55 UTC

[DISCUSS] New VPN implementation based on IKEv2 backed by Vault

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>

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Rohit Yadav <ro...@shapeblue.com>.

Khosrow, I think you can implement your own Vault based CA plugin. However, bear in mind that it will be used for securing KVM hosts and ssvms/cpvms as well. Can you share if any systemvmtemplate change will be required, and how will ipsec configuration/re-configuration work? Also, impact on upgrades?


- Rohit

<https://cloudstack.apache.org>



________________________________
From: Khosrow Moossavi <km...@cloudops.com>
Sent: Thursday, April 5, 2018 3:15:07 AM
To: dev
Subject: Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Thanks Ilya for the feedback.

The way I currently implemented it, two items need to be set in global
settings beforehand:

- you need to specify the VPN implementation (either L2TP or IKEv2)
- then select the PKI engine backend (Vault or Default)

so there won't be any immediate and blocking coupling between
management-server and Vault.

But...

I would argue that we should leverage these new *tools* in our own infra
where Cloudstack runs, such as ELK, RabbitMQ, Kafka, Redis, MongoDB,
or Vault in this particular case. I would assume everyone of us does use
these tools one way or another to keep the infrastructure up an running.
Why not provide an easy, OOB way to do so from ACS itself?

On the other hand, I totally agree that ACS must not fully depend on these
so if any of these were not available ACS won't work. But at the end of the
day ACS is a *webapp* -which does something special of its own- and it
should get help from all the *cool kids*.

On code quality, test coverage and integrations tests I completely 100%
agree.





On Wed, Apr 4, 2018 at 4:53 PM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:

> To complement one thing that Ilya mentioned here. I do not worry much about
> the “requirement” for Vault systems to test ACS. This would be the case if
> Khosrow, when developing, only created tests using what the community calls
> integration tests.
>
> However, it is an implementation from scratch and as such it can and should
> use a very high bar for code quality, which enables proper unit testing for
> all methods. This means, that we can check all of the code in our domain
> (code base) without requiring third-party software. It does not mean that
> we do not need “integration tests” checking the system integration with
> Vault, but we could then restrict this execution to RCs.
>
> On Wed, Apr 4, 2018 at 5:29 PM, ilya musayev <ilya.mailing.lists@gmail.com
> >
> wrote:
>
> > Khosrow
> >
> > My 2c, little less than ideal to manage yet another external end point
> > like.
> >
> > While i understand that it makes it easier to manage certificates - it
> also
> > means going forward - Vault implementation will become a requirement to
> > validate future ACS release.
> >
> > With that said - i do like the proposal and not against it, but:
> > 1) Please consider decoupling it from cloudstack-management server - and
> > release it as server plugin
> > 2) Test coverage must be sufficient enough to validate the functionality
> > (perhaps mock vault endpoints and response)
> >
> > Regards,
> > ilya
> >
> > On Wed, Apr 4, 2018 at 10:49 AM, Khosrow Moossavi <
> kmoossavi@cloudops.com>
> > wrote:
> >
> > > Thanks Paul, the proposed feature will enable the functionality to use
> > > Vault to
> > > act as CA if enabled in ACS, otherwise will fall back to "default"
> > > implementation
> > > which Rohit has already done.
> > >
> > >
> > > On Wed, Apr 4, 2018 at 12:29 PM, Paul Angus <pa...@shapeblue.com>
> > > wrote:
> > >
> > > > 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<http://www.shapeblue.com>
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > @shapeblue
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Rafael Weingärtner <ra...@gmail.com>
> > > > Sent: 04 April 2018 16:51
> > > > To: dev <de...@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
> > > >
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>

rohit.yadav@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Khosrow Moossavi <km...@cloudops.com>.

Thanks Ilya for the feedback.

The way I currently implemented it, two items need to be set in global
settings beforehand:

- you need to specify the VPN implementation (either L2TP or IKEv2)
- then select the PKI engine backend (Vault or Default)

so there won't be any immediate and blocking coupling between
management-server and Vault.

But...

I would argue that we should leverage these new *tools* in our own infra
where Cloudstack runs, such as ELK, RabbitMQ, Kafka, Redis, MongoDB,
or Vault in this particular case. I would assume everyone of us does use
these tools one way or another to keep the infrastructure up an running.
Why not provide an easy, OOB way to do so from ACS itself?

On the other hand, I totally agree that ACS must not fully depend on these
so if any of these were not available ACS won't work. But at the end of the
day ACS is a *webapp* -which does something special of its own- and it
should get help from all the *cool kids*.

On code quality, test coverage and integrations tests I completely 100%
agree.





On Wed, Apr 4, 2018 at 4:53 PM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:

> To complement one thing that Ilya mentioned here. I do not worry much about
> the “requirement” for Vault systems to test ACS. This would be the case if
> Khosrow, when developing, only created tests using what the community calls
> integration tests.
>
> However, it is an implementation from scratch and as such it can and should
> use a very high bar for code quality, which enables proper unit testing for
> all methods. This means, that we can check all of the code in our domain
> (code base) without requiring third-party software. It does not mean that
> we do not need “integration tests” checking the system integration with
> Vault, but we could then restrict this execution to RCs.
>
> On Wed, Apr 4, 2018 at 5:29 PM, ilya musayev <ilya.mailing.lists@gmail.com
> >
> wrote:
>
> > Khosrow
> >
> > My 2c, little less than ideal to manage yet another external end point
> > like.
> >
> > While i understand that it makes it easier to manage certificates - it
> also
> > means going forward - Vault implementation will become a requirement to
> > validate future ACS release.
> >
> > With that said - i do like the proposal and not against it, but:
> > 1) Please consider decoupling it from cloudstack-management server - and
> > release it as server plugin
> > 2) Test coverage must be sufficient enough to validate the functionality
> > (perhaps mock vault endpoints and response)
> >
> > Regards,
> > ilya
> >
> > On Wed, Apr 4, 2018 at 10:49 AM, Khosrow Moossavi <
> kmoossavi@cloudops.com>
> > wrote:
> >
> > > Thanks Paul, the proposed feature will enable the functionality to use
> > > Vault to
> > > act as CA if enabled in ACS, otherwise will fall back to "default"
> > > implementation
> > > which Rohit has already done.
> > >
> > >
> > > On Wed, Apr 4, 2018 at 12:29 PM, Paul Angus <pa...@shapeblue.com>
> > > wrote:
> > >
> > > > 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 <ra...@gmail.com>
> > > > Sent: 04 April 2018 16:51
> > > > To: dev <de...@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
> > > >
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Rafael Weingärtner <ra...@gmail.com>.

To complement one thing that Ilya mentioned here. I do not worry much about
the “requirement” for Vault systems to test ACS. This would be the case if
Khosrow, when developing, only created tests using what the community calls
integration tests.

However, it is an implementation from scratch and as such it can and should
use a very high bar for code quality, which enables proper unit testing for
all methods. This means, that we can check all of the code in our domain
(code base) without requiring third-party software. It does not mean that
we do not need “integration tests” checking the system integration with
Vault, but we could then restrict this execution to RCs.

On Wed, Apr 4, 2018 at 5:29 PM, ilya musayev <il...@gmail.com>
wrote:

> Khosrow
>
> My 2c, little less than ideal to manage yet another external end point
> like.
>
> While i understand that it makes it easier to manage certificates - it also
> means going forward - Vault implementation will become a requirement to
> validate future ACS release.
>
> With that said - i do like the proposal and not against it, but:
> 1) Please consider decoupling it from cloudstack-management server - and
> release it as server plugin
> 2) Test coverage must be sufficient enough to validate the functionality
> (perhaps mock vault endpoints and response)
>
> Regards,
> ilya
>
> On Wed, Apr 4, 2018 at 10:49 AM, Khosrow Moossavi <km...@cloudops.com>
> wrote:
>
> > Thanks Paul, the proposed feature will enable the functionality to use
> > Vault to
> > act as CA if enabled in ACS, otherwise will fall back to "default"
> > implementation
> > which Rohit has already done.
> >
> >
> > On Wed, Apr 4, 2018 at 12:29 PM, Paul Angus <pa...@shapeblue.com>
> > wrote:
> >
> > > 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 <ra...@gmail.com>
> > > Sent: 04 April 2018 16:51
> > > To: dev <de...@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
> > >
> >
>



-- 
Rafael Weingärtner

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by ilya musayev <il...@gmail.com>.

Khosrow

My 2c, little less than ideal to manage yet another external end point
like.

While i understand that it makes it easier to manage certificates - it also
means going forward - Vault implementation will become a requirement to
validate future ACS release.

With that said - i do like the proposal and not against it, but:
1) Please consider decoupling it from cloudstack-management server - and
release it as server plugin
2) Test coverage must be sufficient enough to validate the functionality
(perhaps mock vault endpoints and response)

Regards,
ilya

On Wed, Apr 4, 2018 at 10:49 AM, Khosrow Moossavi <km...@cloudops.com>
wrote:

> Thanks Paul, the proposed feature will enable the functionality to use
> Vault to
> act as CA if enabled in ACS, otherwise will fall back to "default"
> implementation
> which Rohit has already done.
>
>
> On Wed, Apr 4, 2018 at 12:29 PM, Paul Angus <pa...@shapeblue.com>
> wrote:
>
> > 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 <ra...@gmail.com>
> > Sent: 04 April 2018 16:51
> > To: dev <de...@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
> >
>

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Khosrow Moossavi <km...@cloudops.com>.

Thanks Paul, the proposed feature will enable the functionality to use
Vault to
act as CA if enabled in ACS, otherwise will fall back to "default"
implementation
which Rohit has already done.


On Wed, Apr 4, 2018 at 12:29 PM, Paul Angus <pa...@shapeblue.com>
wrote:

> 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 <ra...@gmail.com>
> Sent: 04 April 2018 16:51
> To: dev <de...@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 <km...@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
>

RE: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Paul Angus <pa...@shapeblue.com>.

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 <ra...@gmail.com> 
Sent: 04 April 2018 16:51
To: dev <de...@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 <km...@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

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Rafael Weingärtner <ra...@gmail.com>.

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 <km...@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

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Khosrow Moossavi <km...@cloudops.com>.

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 <km...@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
>

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Rafael Weingärtner <ra...@gmail.com>.

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 <km...@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

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Khosrow Moossavi <km...@cloudops.com>.

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 <km...@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
>

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Rafael Weingärtner <ra...@gmail.com>.

So, you need a certificate that is signed by the CA that is used by the VPN
service. Is that it?



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.




On Wed, Apr 4, 2018 at 11:22 AM, Khosrow Moossavi <km...@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

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Khosrow Moossavi <km...@cloudops.com>.

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 <km...@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
>

Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault

Posted by Rafael Weingärtner <ra...@gmail.com>.

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 <km...@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