Thanks Ilya for the feedback. The way I currently implemented it, two items need to be set in global settings beforehand:
- you need to specify the VPN implementation (either L2TP or IKEv2) - then select the PKI engine backend (Vault or Default) so there won't be any immediate and blocking coupling between management-server and Vault. But... I would argue that we should leverage these new *tools* in our own infra where Cloudstack runs, such as ELK, RabbitMQ, Kafka, Redis, MongoDB, or Vault in this particular case. I would assume everyone of us does use these tools one way or another to keep the infrastructure up an running. Why not provide an easy, OOB way to do so from ACS itself? On the other hand, I totally agree that ACS must not fully depend on these so if any of these were not available ACS won't work. But at the end of the day ACS is a *webapp* -which does something special of its own- and it should get help from all the *cool kids*. On code quality, test coverage and integrations tests I completely 100% agree. On Wed, Apr 4, 2018 at 4:53 PM, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote: > To complement one thing that Ilya mentioned here. I do not worry much about > the “requirement” for Vault systems to test ACS. This would be the case if > Khosrow, when developing, only created tests using what the community calls > integration tests. > > However, it is an implementation from scratch and as such it can and should > use a very high bar for code quality, which enables proper unit testing for > all methods. This means, that we can check all of the code in our domain > (code base) without requiring third-party software. It does not mean that > we do not need “integration tests” checking the system integration with > Vault, but we could then restrict this execution to RCs. > > On Wed, Apr 4, 2018 at 5:29 PM, ilya musayev <ilya.mailing.li...@gmail.com > > > wrote: > > > Khosrow > > > > My 2c, little less than ideal to manage yet another external end point > > like. > > > > While i understand that it makes it easier to manage certificates - it > also > > means going forward - Vault implementation will become a requirement to > > validate future ACS release. > > > > With that said - i do like the proposal and not against it, but: > > 1) Please consider decoupling it from cloudstack-management server - and > > release it as server plugin > > 2) Test coverage must be sufficient enough to validate the functionality > > (perhaps mock vault endpoints and response) > > > > Regards, > > ilya > > > > On Wed, Apr 4, 2018 at 10:49 AM, Khosrow Moossavi < > kmooss...@cloudops.com> > > wrote: > > > > > 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 > > > > > > > > > > > > > -- > Rafael Weingärtner >
