Open Stack

On Tue, Dec 02, 2014 at 01:31:39PM -0500, Rob Crittenden wrote:
> Georgios Dimitrakakis wrote:
> > Hi Rob!
> > 
> > Thanks for you detailed explanation.
> > Just a few more questions to clarify things....
> > 
> > So if I decide to go natively is it sufficient to follow the steps on
> > the two blog posts? Do I have to do anything more than that? I am
> > specifically interested in EC2 which is excluded.....Can we foresee the
> > impact on the performance and why is that?
> 
> I haven't done much with EC2 so I can't say with any authority. You
> might check how it is configured in devstack for some pointers.
> 
> The presumed problem with native SSL is that due to the GIL only one
> request can effectively be served at a time. I don't know that anyone
> has actually tested that but at the Atlanta summit whenever I brought up
> native SSL most everyone recoiled. Things will be different if/when all
> services run in Apache.
> 
> > If I decide to go with HAProxy (no hardware proxy available) do I still
> > have to change the endpoints to httpS or changing the ports is
> > sufficient? Do you happen to know where can I find more info regarding
> > this?
> 
> By my understanding, yes. If anything looks up the endpoints in Keystone
> and they get back http endpoints then you get an in-the-clear request to
> your proxy listening on SSL, so nothing will work. I don't know how the
> guys with hardware handle it.

This sounds about right. If you are terminating SSL in haproxy, the
backend connection (from haproxy to the service) is still
unencrypted. However, you can very easily tell haproxy to force HTTPS
for any HTTP connection. In other words, if you connect to the service
over HTTP, redirect to HTTPS.

> I'd recommend toying with this in devstack to get a feel for how things
> would work. You can add ENABLED_SERVICES+=,tls-proxy to local.conf and
> it will set things up using stud as the proxy. You'll be able to see how
> the endpoints get set up and what the configuration files will look like.
> 
> The biggest pain right now with using SSL is distributing and using the
> CA certificate. You'll be tempted to use --insecure. Avoid that
> temptation if at all possible. Ubuntu/Fedora/RHEL/CentOS (and perhaps
> Debian, I didn't check) all have a way of publishing the CA certificate
> centrally. That can alleviate many of the problems on the server and
> clients.

Agreed.

Ryan

> rob
> 
> > 
> > 
> > All the best,
> > 
> > 
> > George
> > 
> > 
> > 
> > On Tue, 02 Dec 2014 10:31:30 -0500, Rob Crittenden wrote:
> >> Georgios Dimitrakakis wrote:
> >>> @Robert: I don't have a load-balancer for this deployment. Just
> >>> controller, cinder and compute nodes.
> >>>
> >>>
> >>>
> >>> What I would like to do is to secure the public endpoints for Keystone,
> >>> Glance, Nova, Cinder with SSL and the EC2 API.
> >>>
> >>> That would be sufficient for the moment.
> >>>
> >>> Is it OK if I just change the respective *.conf files or should I do
> >>> something more? Should the changes at the *.conf files be propagated on
> >>> all nodes?
> >>
> >> It is a bit more complicated than that.
> >>
> >> You can either secure things natively or use a TLS proxy (hardware or
> >> something like haproxy or stud). Native SSL is generally frowned upon
> >> since the assumption is that performance will be terrible due to the
> >> python GIL.
> >>
> >> What you do with haproxy or stud is to modify the port that the services
> >> normally listen on (in devstack we simply add 1 to each of the ports)
> >> and configure the proxy to listen on the "standard" ports for each
> >> service.
> >>
> >> You also need secure endpoints defined in keystone for everything. If
> >> you've got an existing installation you'll need to try to convert it.
> >>
> >> I've been toying with SSL in devstack and documented some experiments I
> >> did including converting Keystone to use native SSL,
> >> http://blog-rcritten.rhcloud.com/?p=5 and subsequently converting nova,
> >> glance and cinder in the same install
> >> http://blog-rcritten.rhcloud.com/?p=26
> >>
> >> This is for native SSL, which as I said is generally frowned up, but I
> >> was just toying after all. The process should be similar for a proxy.
> >>
> >> rob
> >>
> >>>
> >>>
> >>> All the best,
> >>>
> >>> George
> >>>
> >>>
> >>>
> >>> On Tue, 2 Dec 2014 17:49:24 +0330, Muhammed Salehi wrote:
> >>>> Hi.
> >>>> Do you want to serve https instead http ? Or you want to encrypt all
> >>>> of the communications between these components?
> >>>> For the first problem the solution is : Search about how to serve and
> >>>> https with apache or passenger.
> >>>>
> >>>> On Tue, Dec 2, 2014 at 5:22 PM, Georgios Dimitrakakis  wrote:
> >>>>
> >>>>> Hi!
> >>>>>
> >>>>> Can someone point me to the right direction on how to secure
> >>>>> publicly available services (e.g. nova,keystone,glance) with an SSL
> >>>>> certificate?
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> George
> >>>>>
> >>>>> _______________________________________________
> >>>>> Mailing list:
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
> >>>>> Post to     : openstack at lists.openstack.org [2]
> >>>>> Unsubscribe :
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [3]
> >>>>
> >>>> -- 
> >>>>
> >>>> -----BEGIN PGP PUBLIC KEY BLOCK-----
> >>>> Version: GnuPG v1
> >>>>
> >>>> mQENBFRX8IoBCADCn76BbNN5m/GwP1rWaOvZMYfdm4Tv9oJehK7zAAzrHPZOaV/i
> >>>> kdxG6LGadCGh/uTWoos441A8MKN/GufruEz1jvR+rgamD0oiTdRHTXz3Wkzcd62y
> >>>> +U9pNLmYZyLUM1ebXXoxgmdNMGHvYLbdTIFgmxfIthKzRx9vd5WQGnsg/gFLTcdY
> >>>> cWd5/THfkImJUHmjLAOepcewQcODijTp27xMwK354SG0BwbWroGAj5AVRqXqD6Qg
> >>>> vO5zIgfMUsoOTMVF5WhAAf1xAjjGjEDi9EqeV1EVyO83s54gfAH/pWYV0K0RZvRw
> >>>> h96wxZVVmCq9Ys8aU8D+hOjEvkjHZPAd3uNXABEBAAG0NFNleXllZCBNdWhhbW1l
> >>>> ZCBTYWRlZ2ggU2FsZWhpIDxzYWxlaGkxOTk0QGdtYWlsLmNvbT6JAT4EEwECACgF
> >>>> AlRX8IoCGwMFCQHhM4AGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEKs5CKNB
> >>>> Z6zv/JQIALd5MnRhvAatGl/HcTYrm/S2Vsp3LgvC6R/w2uNiTm9tfSf596+2flF7
> >>>> xgWUdROZ5O7s188oWiZRNb88XjdMMJtl0KpNpxLbYRyNPZL0klAps46Wlmy3fr8m
> >>>> 7RdovLSy2QtmFtEAsXfYyXmLGB4PeexqYyfcXYhfP1W4kyTScBRUZ4SuFWDhBvvZ
> >>>> 8vHHhWjiPVFvgi1cX3rwqtzp4eYFTHeH8QhKDeDk3760XVMk+jl+kvzqUzwh5V6+
> >>>> SJs63YoiTSXyk37844NOGvYDHsupDO0R4O+YBwcZLxah/nqfTodfAnsmOA6W6oOy
> >>>> lnVOH4IwrfcoVyjjqIlLWGws7BkPN6+5AQ0EVFfwigEIALLGTAxtT7lLuywmNTaq
> >>>> hqpUtYsOWx7Cxjj1tVfG3bN/PbW+nKFvfyJkURYVyjn4z7GHLVCrYIr9ixhBRFcz
> >>>> zmHuMkxMEr5u/m+H8CSsZ02V81v6+1uM2NvPxCYCUqDxEbcPrs8XrmPZGINY2Fya
> >>>> XLpljTh06s1vdBAk32Wxy2Vz6Ii6pQD5WDgrdgDOgpTTlPdIxg9eq6yZi+GMJj/4
> >>>> 28Rt6HJhGaqGXN0bCPQ78tQygcY4EDQwpkToWxLCizsj1+9XFwwjnOQON/FNsAT7
> >>>> g+XsVQJKfGmRe2QuRJ9oqSK6pi16O7VXg6bAw1dLsEmNoSto1ofy7DVTqqSlEG2o
> >>>> N0MAEQEAAYkBJQQYAQIADwUCVFfwigIbDAUJAeEzgAAKCRCrOQijQWes7xemB/92
> >>>> 1PRHt24/hfCKR86aCnZk8bzNP+HDeewHXmFLEk9Hk7k2kuo6zVLjPnMA4M9rgOwh
> >>>> W5EYhyVpNWKnzzhMwyCGz0J7doK2HYRXJKez1RErLW4GPLzM+4sfY5pWBAjDY62e
> >>>> 1Tz1ay+fS3CLh4zCCZYqraHKa6PJYYp9Bz3NRj3xkFtkcLspNq4DkiEBPJVLIPko
> >>>> OkVOpBuNpj1YDSZZXwM8HzDMvJc1qgAVxWk56BjePrx8SHfDah1UQqZst4dWeepJ
> >>>> 0E2xj4H+WMrIW/3btSTVdlr4zPFwGQ9qE2CcbDJJhH68U9eve3njEPDFiu1TS/f5
> >>>> Tt1scwgVintCWdVX9BS2
> >>>> =cxjk
> >>>> -----END PGP PUBLIC KEY BLOCK-----
> >>>>
> >>>>
> >>>> Links:
> >>>> ------
> >>>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >>>> [2] mailto:openstack at lists.openstack.org
> >>>> [3] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >>>> [4] mailto:giorgis at acmac.uoc.gr
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list:
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >>> Post to     : openstack at lists.openstack.org
> >>> Unsubscribe :
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > 
> > -- 
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack