From dev-return-111208-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org Wed Apr 4 17:38:50 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B133118064F for ; Wed, 4 Apr 2018 17:38:49 +0200 (CEST) Received: (qmail 25504 invoked by uid 500); 4 Apr 2018 15:38:48 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 25424 invoked by uid 99); 4 Apr 2018 15:38:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Apr 2018 15:38:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 4CC301A102B for ; Wed, 4 Apr 2018 15:38:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_SHORT=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=cloudops.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id yv7we6Id2h-C for ; Wed, 4 Apr 2018 15:38:44 +0000 (UTC) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id D3FB95FB37 for ; Wed, 4 Apr 2018 15:38:43 +0000 (UTC) Received: by mail-ua0-f182.google.com with SMTP id n20so13497488ual.7 for ; Wed, 04 Apr 2018 08:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudops.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=DxeBjtmj4sds3mg1E/buRNYi72fJQ748aFggC16GuZY=; b=ePZnKPNC+3m4iWzrJhkThS7mgCedRd+U5DurVakkuBWr6NLiGeIwKHiLOUcwL1Cpdw mOqRvf9Us0bQbCpnE3vUgLXWpAHJXIJjHuvcVq0usNi77l1vuAxTMa8QNlIP45LtSqqD hmtpQ2KM5rzEu60noy3aJcygl/tNTMEKM6a2k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DxeBjtmj4sds3mg1E/buRNYi72fJQ748aFggC16GuZY=; b=LkkBkbJ87waBwyLGKifj92OWyIsJn6Kj9keyvVa2Ffc9hOT6PxO4YOElklYCAWynSz jHczhS4M8LF5ogolqfJNz3H0bDYmaDGWsQ78LcG1OKHYdedVGL5kbK0DNgYh7eUWxV2E oQTYbiSRXf/RlUudW0i41ez46oIfIemdcHL1J0EAmM7CME9MkHr5qtXpbspmL2BjhkIk P1C92EZXD0A106V4jTwvSTNpsb7SCe0MoUfUtF4A/p0ImHVG+oSKvT8SU8gcA47B2PZQ 0NNdXuBfEzNupwEnyfMNv0OQjIYF7uY6NoXSrNhf4vMOD5r1nznZNKRhJUXfGW+AfKUa kRYQ== X-Gm-Message-State: ALQs6tAIeb06kjKgiFhCUT02+xolAYgJ/enXVwH5XFNgezLLiUo8vD6c GeDIZBBqHqei9lMSnEcocKBnGNZcDa20L1iuXwDSs0z+mw== X-Google-Smtp-Source: AIpwx4+//1OTKHMtf7ClKgKXxPyEyhvum2DPCFWTH5VCGg4g0G0IDLsC07eZaQvyP+x4qw33OgXra8FT+n2x2XA0S8c= X-Received: by 10.176.80.217 with SMTP id d25mr11481743uaa.88.1522856322582; Wed, 04 Apr 2018 08:38:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.109 with HTTP; Wed, 4 Apr 2018 08:38:12 -0700 (PDT) In-Reply-To: References: From: Khosrow Moossavi Date: Wed, 4 Apr 2018 11:38:12 -0400 Message-ID: Subject: Re: [DISCUSS] New VPN implementation based on IKEv2 backed by Vault To: dev Content-Type: multipart/alternative; boundary="94eb2c1927a826e52b0569079edc" --94eb2c1927a826e52b0569079edc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=A4rtner < 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 > wrote: > > > On Wed, Apr 4, 2018 at 10:36 AM, Rafael Weing=C3=A4rtner < > > rafaelweingartner@gmail.com> wrote: > > > > > So, you need a certificate that is signed by the CA that is used by t= he > > 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 specifi= c > > 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 th= e > > "Server > > Certificate" and "Server Private Key" are sensitive information and onl= y > > exist on > > VR. > > > > User then can go ahead and install the Root CA on their local machine a= nd > > 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 ti= me > > > 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 V= PN > > 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=C3=A4rtner < > > > > 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=E2=80=99s 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 feature= s > > > (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 i= t > > can > > > > > easily > > > > > > be extended/implemented with other > > > > > > concrete classes or designs (such as going forward with in-hous= e > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Rafael Weing=C3=A4rtner > > > > > > > > > > > > > > > > > > > > > -- > > > Rafael Weing=C3=A4rtner > > > > > > > > > -- > Rafael Weing=C3=A4rtner > --94eb2c1927a826e52b0569079edc--