OSDir


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

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


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 <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