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 <paul.an...@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.an...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > > -----Original Message----- > From: Rafael Weingärtner <rafaelweingart...@gmail.com> > Sent: 04 April 2018 16:51 > To: dev <dev@cloudstack.apache.org> > Subject: Re: [DISCUSS] New VPN implementation based on IKEv2 backed by > Vault > > Thanks for sharing the details. Now I have a better perspective of the > proposal.It is an interesting integration of CloudStack VPN service with > Vault PKI feature. > > On Wed, Apr 4, 2018 at 12:38 PM, Khosrow Moossavi <kmooss...@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 < > > rafaelweingart...@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 < > > kmooss...@cloudops.com> > > > wrote: > > > > > > > On Wed, Apr 4, 2018 at 10:36 AM, Rafael Weingärtner < > > > > rafaelweingart...@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 < > > > > kmooss...@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 < > > > > > > rafaelweingart...@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 < > > > > > kmooss...@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 >
