OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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@xxxxxxxxxxxx>
wrote:

> On Wed, Apr 4, 2018 at 10:36 AM, Rafael Weingärtner <
> rafaelweingartner@xxxxxxxxx> 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@xxxxxxxxxxxx>
> > 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@xxxxxxxxx> 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@xxxxxxxxxxxx
> > > >
> > > > 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