Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
Hi, On Thu, Sep 11, 2014 at 1:03 PM, Sebastian Kalinowski < skalinow...@mirantis.com> wrote: > I have some topics for [1] that I want to discuss: > > 1) Should we allow users to turn SSL on/off for Fuel master? > I think we should since some users may don't care about SSL and > enabling it will just make them unhappy (like warnings in browsers, > expiring certs). > > Definitely +1. I think that Tomasz mentioned somewhere that HTTP should be kept as the default. > 2) Will we allow users (in first iteration) to use their own certs? > If we will (which I think we should and other people aslo seems to > share this point of view), we have some options for that: > A) Add informations to docs where to upload your own certificate on > master node (no UI) - less work, but requires a little more action from > users > B) Simple form in UI where user will be able to paste his certs - > little bit more work, user friendly > Are there any reasons we shouldn't do that? > > Option A is enough. If there is enough time to implement option B, that's cool but this should not be a blocker. > 3) How we will manage cert expiration? > Stanislaw proposed that we should show user a notification that will > tell user about cert expiration. We could check that in cron job. > I think that we should also allow user to generate a new cert in Fuel > if the old one will expire. > As long as the user cannot upload a certificate, we don't need to care about this point but it should be mentioned in the doc. And to avoid this problem, Fuel should generate certificates that expire in many years (eg >= 10). BR Simon > > I'll also remove part about adding cert validation in fuel agent since it > would require a significant amount of work and it's not essential for first > iteration. > > Best, > Sebastian > > > [1] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
I have some topics for [1] that I want to discuss: 1) Should we allow users to turn SSL on/off for Fuel master? I think we should since some users may don't care about SSL and enabling it will just make them unhappy (like warnings in browsers, expiring certs). 2) Will we allow users (in first iteration) to use their own certs? If we will (which I think we should and other people aslo seems to share this point of view), we have some options for that: A) Add informations to docs where to upload your own certificate on master node (no UI) - less work, but requires a little more action from users B) Simple form in UI where user will be able to paste his certs - little bit more work, user friendly Are there any reasons we shouldn't do that? 3) How we will manage cert expiration? Stanislaw proposed that we should show user a notification that will tell user about cert expiration. We could check that in cron job. I think that we should also allow user to generate a new cert in Fuel if the old one will expire. I'll also remove part about adding cert validation in fuel agent since it would require a significant amount of work and it's not essential for first iteration. Best, Sebastian [1] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
On Wed, Sep 10, 2014 at 2:40 PM, Tomasz Napierala wrote: > > Regarding > After careful consideration, I think that for 6.0 we will only be able to > implement [2] with limited functionality. In terms of certificate > management, we could offer uploading customer generated cert (and maybe > provide shot doc on how to spawn CA + sign certs) > After 6.0 we can concentrate on proper implementation of CA management, > and then allow Fuel master node part to use it. > > [1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment > [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints > [3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints So if I understand correctly the idea is that we implement basic functionality for [2] and [3] especially for the management of the certificate. I guess that even if [2] and [3] are managing a self-signed certificate by their own the code that does this could be share. And then concentrate on the CA management. Thus I removed the dependency to [1] and I consider that in [3] we should implement a limited functionality as described above for [2]. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
Hi, Tomasz is right. Let's try not to complicate the things. For 6.0 we'll allow just upload key, csr, certificate (like 3 edit boxes), or these edit boxes will be greyed if customer allows to generate self-signed certificates. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Sep 10, 2014 at 1:40 PM, Tomasz Napierala wrote: > > On 10 Sep 2014, at 12:54, Simon Pasquier wrote: > > > Hello, > > > > Lets back up a bit and list the different options for Fuel users: > > 0/ The user is happy with plain HTTP. > > => Already supported :) > > 1/ The user wants HTTPS but doesn't want the burden associated with > certificate management. > > => Fuel creates and manages the SSL certificates, be them self-signed or > signed by some internal CA. > > => Using an internal CA instead of multiple self-signed certificates is > cleaner as you explained. > > 2/ The user wants HTTPS and wants to use certificates which are > generated by an external source (either some internal corporate PKI or some > public certificate authority) > > => Fuel supports certificate + key uploads > > => It should be possible to tell Fuel which entity (Fuel, OSt > environment) uses which certificate > > 3/ The user wants HTTPS and agrees to let Fuel generating certificates > on behalf of some corporate PKI. > > => Fuel supports CA + key uploads > > > > I think that option 1 is the way to go for a first approach. Option 2 is > definitely something that end-users would need at some point. I'm less > convinced by option 3: if I were a PKI admin, I'll be reluctant to let Fuel > generate certificates on its own. Also my gut feeling tells me that > implementing 1 & 2 is already quite a lot of work. > > > > I've also added some questions/comments inline. > > Regarding > After careful consideration, I think that for 6.0 we will only be able to > implement [2] with limited functionality. In terms of certificate > management, we could offer uploading customer generated cert (and maybe > provide shot doc on how to spawn CA + sign certs) or if user does not want > to do it, generate simple self signed cert and install it on Fuel http > server and let user download it. > > After 6.0 we can concentrate on proper implementation of CA management, > and then allow Fuel master node part to use it. > > [1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment > [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints > [3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints > -- > Tomasz 'Zen' Napierala > Sr. OpenStack Engineer > tnapier...@mirantis.com > > > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
On 10 Sep 2014, at 12:54, Simon Pasquier wrote: > Hello, > > Lets back up a bit and list the different options for Fuel users: > 0/ The user is happy with plain HTTP. > => Already supported :) > 1/ The user wants HTTPS but doesn't want the burden associated with > certificate management. > => Fuel creates and manages the SSL certificates, be them self-signed or > signed by some internal CA. > => Using an internal CA instead of multiple self-signed certificates is > cleaner as you explained. > 2/ The user wants HTTPS and wants to use certificates which are generated by > an external source (either some internal corporate PKI or some public > certificate authority) > => Fuel supports certificate + key uploads > => It should be possible to tell Fuel which entity (Fuel, OSt environment) > uses which certificate > 3/ The user wants HTTPS and agrees to let Fuel generating certificates on > behalf of some corporate PKI. > => Fuel supports CA + key uploads > > I think that option 1 is the way to go for a first approach. Option 2 is > definitely something that end-users would need at some point. I'm less > convinced by option 3: if I were a PKI admin, I'll be reluctant to let Fuel > generate certificates on its own. Also my gut feeling tells me that > implementing 1 & 2 is already quite a lot of work. > > I've also added some questions/comments inline. Regarding After careful consideration, I think that for 6.0 we will only be able to implement [2] with limited functionality. In terms of certificate management, we could offer uploading customer generated cert (and maybe provide shot doc on how to spawn CA + sign certs) or if user does not want to do it, generate simple self signed cert and install it on Fuel http server and let user download it. After 6.0 we can concentrate on proper implementation of CA management, and then allow Fuel master node part to use it. [1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints [3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
Hello, Thanks for the detailed email, Stanislaw. Your suggestion of deploying a CA container is really interesting. Especially for OSTF and other testing since the tools only need to know about the "root" CA. Lets back up a bit and list the different options for Fuel users: 0/ The user is happy with plain HTTP. => Already supported :) 1/ The user wants HTTPS but doesn't want the burden associated with certificate management. => Fuel creates and manages the SSL certificates, be them self-signed or signed by some internal CA. => Using an internal CA instead of multiple self-signed certificates is cleaner as you explained. 2/ The user wants HTTPS and wants to use certificates which are generated by an external source (either some internal corporate PKI or some public certificate authority) => Fuel supports certificate + key uploads => It should be possible to tell Fuel which entity (Fuel, OSt environment) uses which certificate 3/ The user wants HTTPS and agrees to let Fuel generating certificates on behalf of some corporate PKI. => Fuel supports CA + key uploads I think that option 1 is the way to go for a first approach. Option 2 is definitely something that end-users would need at some point. I'm less convinced by option 3: if I were a PKI admin, I'll be reluctant to let Fuel generate certificates on its own. Also my gut feeling tells me that implementing 1 & 2 is already quite a lot of work. I've also added some questions/comments inline. BR, Simon On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin wrote: > I think that if we have 3 blueprints that realises some SSL stuff around > themselves then we can discuss it here. > My vision about SSL in Fuel split into 3 parts: > > A) We need to implement [1] blueprint, cause it is only one way to > generate certificates. > How i see that: > 1.0 We sync puppet-openssl from upstream, adapt it for Fuel tasks. > 1.1 We create docker container (we already have many, so containerized > CA should work well) with OpenSSL and puppet manifests in it. > 1.2 When container will start first time, it will create CA that will > store on master node. > > Our workitems here is: > - Create docker container > - Sync upstream puppet-openssl and adapt it for Fuel > - Write code to create CA > First of all I think this blueprint should be submitted to fuel-specs ;) How do you see the exchanges between the CA container and the various services? For instance, how would nailgun asks for a signed certificate and get back the result? > > B) We need to implement [2] blueprint. How I see that: > 1.3 When CA container start first time and creates CA, then it will > check for keypair for master node (Fuel UI). If that keypair will not > found, then CA create it, change nginx conffile properly and restart nginx > on master node. > > I find awkward to have the CA container restarting nginx... > Our workitems here is: > - Write code to check if we already have generated certificate and > generate new if we have not. > > C) Then we need to implement [3] blueprint > For next step we have 2 options: > First: > 1.3 When we create new cluster then we know all information to create > new keypair(s). When user press "Deploy changes" button, then we will > create new keypair(s). > Q: Main question here is - how many keypairs we will create? One for every > service or one for all? > As a first implementation, I assume that one certificate for all OSt services is good enough. > 1.4 We will distribute key(s) with mcollective agent (similar to how > we sync puppet manifests from master node to other nodes). After that > private key(s) will deleted from master node. > How will it work if the user modifies the configuration of the environment afterwards? Say he/she adds one controller node, how will it be able to copy the private key to the new node? > 1.5 On nodes puppet will do all work. We need to write some code for > that > Pros of that method: > + It's relative simple, we can create clean and lucid code that > will be easy for support > Cons of that method: > - We need to send every private key over network. We can reduce > this danger cause we will already have passwordless sync over network > between master node and other nodes, cause we will generate ssh keys for > nodes before we will distribute any data at deployment stage. > > Second: > 1.3 When we create new cluster, we do all work same way as we do it > now, but after provisioning we will create keypair on first node, make csr > for every service (or for one, if we will create one certificate for all > services) and send that csr to master node, where it will signed and > certificate will send back. > 1.4 Puppet will do all work on nodes. We, obviously, need to write > some code for it. But we need to sync our keys over controllers all the > same (and now we don't have reliable mechanism to do this) > Pros of that method: > + I don't see any > Cons of that method:
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin wrote: > >So I think that we need to start on [3]. As this is required for OSt > public > >endpoint SSL and also for Fuel SSL it can be quicker to make a first stage > >where a self-signed certificate is managed from nailgun and a second stage > >with the docker CA... > So, yes, I think that it is good idea, cause it will be good base for [2] > and [3] > > [1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment > [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints > [3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints > +1 I totally agree that we should start with [1] first and later focus on [2] and [3]. I'll also update [2] to adjust it to the plan you proposed. Best, Sebastian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [FUEL] Re: SSL in Fuel.
I think that if we have 3 blueprints that realises some SSL stuff around themselves then we can discuss it here. My vision about SSL in Fuel split into 3 parts: A) We need to implement [1] blueprint, cause it is only one way to generate certificates. How i see that: 1.0 We sync puppet-openssl from upstream, adapt it for Fuel tasks. 1.1 We create docker container (we already have many, so containerized CA should work well) with OpenSSL and puppet manifests in it. 1.2 When container will start first time, it will create CA that will store on master node. Our workitems here is: - Create docker container - Sync upstream puppet-openssl and adapt it for Fuel - Write code to create CA B) We need to implement [2] blueprint. How I see that: 1.3 When CA container start first time and creates CA, then it will check for keypair for master node (Fuel UI). If that keypair will not found, then CA create it, change nginx conffile properly and restart nginx on master node. Our workitems here is: - Write code to check if we already have generated certificate and generate new if we have not. C) Then we need to implement [3] blueprint For next step we have 2 options: First: 1.3 When we create new cluster then we know all information to create new keypair(s). When user press "Deploy changes" button, then we will create new keypair(s). Q: Main question here is - how many keypairs we will create? One for every service or one for all? 1.4 We will distribute key(s) with mcollective agent (similar to how we sync puppet manifests from master node to other nodes). After that private key(s) will deleted from master node. 1.5 On nodes puppet will do all work. We need to write some code for that Pros of that method: + It's relative simple, we can create clean and lucid code that will be easy for support Cons of that method: - We need to send every private key over network. We can reduce this danger cause we will already have passwordless sync over network between master node and other nodes, cause we will generate ssh keys for nodes before we will distribute any data at deployment stage. Second: 1.3 When we create new cluster, we do all work same way as we do it now, but after provisioning we will create keypair on first node, make csr for every service (or for one, if we will create one certificate for all services) and send that csr to master node, where it will signed and certificate will send back. 1.4 Puppet will do all work on nodes. We, obviously, need to write some code for it. But we need to sync our keys over controllers all the same (and now we don't have reliable mechanism to do this) Pros of that method: + I don't see any Cons of that method: - Code will be not so obvious - To generate cert we need to rely to other service (network) and if network will unreachable then csr signing will fail and all following deployment will fail because we will not have valid certificate Independing of choice (first or second), our workitems here is: - Write code to provide functions about generating keypairs, csr's and signing them. 1.5. When we have created CA and certs for services, we can do usual puppet apply to deploy changes. Workitems on that stage: - Sync upstream modules that already have big changes to SSL support (e.g. HAProxy) and adapt that modules to Fuel usage - Rewrite some of manifests to support https support As I see, at that phase we can say that Stage I for blueprint [3] is ready. What we can do next? My thoughts is that: 2. We need to think about use case when user want to import his own certificate to Fuel or Openstack services endpoints (cause in that case users will not see warning popup in browser about not trusted certificate or cause corporate policy say to do that). I see that way: 2.1 We can provide ability to change some keypairs (e.g. for Fuel UI and Horizon) Q: How many keys user can change? We can provide ability to change all keys (but why we need to do that?) Q: If user will replace some of keys with his own key - how we will check that it is not some malicious but valid user key? Or we will trust all keys by default? To do that we will need to change: - Some UI changes to provide ability to upload user keys - Some Nailgun and Astute changes to operate with new keys - Some puppet manifest changes to apply new keys and restart services - Some changes to check basic validity of uploaded keys (expiry date, key length, key type) 3. We can give user ability to change CA keypair (if user trust certificate from that keypair then he automatically will trust all certificates that will signed with that CA, so if user company trusted CA issue cross-sertificate for Fuel then user automatically will agree that all certificates in deployed by Fuel services is trusted). For do that we need: - Some UI changes to provide ability to upload user CA key - Some Nailgun and Astute changes to operate with new CA keys - Write so
