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
