General SSL support for all public endpoints including spice

[BjoernT]

Currently most RPCv9 public endpoints are configured with an external IP but unfortunately the protocol is hard coded to http://{{ external_vip_address}} although we only open SSL public VIP on the outside. Ergo public endpoints are not working in RPC. I personally would go over to use a hostname instead an IP for the endpoints, that greatly benefits SSL that the hostname can match SSL common name, an IP never will. Additionally we add the flexibility to steer endpoints over host entries and don't necessarily have to have endpoint type variables in the environment pre-configured, most customers probably would forget anyway. To summarize this request:

• Add protocol options for all endpoint types, HTTP or HTTPS
• Add SSL support for Spice (TLS/Apache?)
• Add hostname support for endpoints to drop IPs all together

Adding @cfarquhar

[cloudnull]

Regarding "Add protocol options for all endpoint types": In RPC9/10 we have no endpoints that are "hard coded". The endpoints are all specified in the rpc_deployment/vars/openstack_service_vars/*endpoints.yml and are able to edited to suite your needs, IE: setting the scheme from "http" to "https" for publicURL by changing the variable service_publicurl. What change would you like to see which could not be accomplished by simply editing the variable files?

Regarding "Add SSL support for Spice": While the built in spice server can support SSL we should look at putting it behind Apache using something similar to what we are doing in keystone_apache which will better support SSL than the native server.

Regarding "Add hostname support for endpoints to drop IPs all together": Do you envision this to be a change in inventory to not use _containeraddress, _ansible_sshhost and the like, or would this only effect the variables _external_vipaddress and _internal_vipaddress? Do think that we would need to add host entries on all machines to reference the domain name or setup some type of internal DNS server, or would it be expected that user has there own DNS resolvers (public or otherwise)? What is preventing you from using domain names in your endpoints now?

[claco]

Re: #3. There is a page on the one wiki around what the plans are for SSL and all of the processes and questions (not just ansible code changes). As of the last SSL spike, and ssl would be external vip only, and there are variations depending on if that ip is the lb vip, or the firewall ip.

[odyssey4me]

I've historically had great success with using an Apache reverse proxy setup for Horizon, NoVNC and the endpoints.

This means that all the OpenStack service can be setup using their native services (some of them don't work when setup as a wsgi process under apache), they can remain HTTP instead of HTTPS internally (there are still client bugs which either don't work with HTTPS properly or don't respect the setting telling them to use a specific endpoint), and all internal processes don't need to know anything about the DNS names, certificates and other such complexities... it's only end-users who need to know. Another advantage of using this approach is that we don't really have to increase our testing matrix too much or increase the complexity of any of the deployment code.

Typically to resolve the IP vs Name issue I've used the substitution module on the reverse proxy to do inline search and replace on the endpoint requests and responses. That way the clients never know that the back-end is configured with IP's - they only ever see the names and the https endpoints.

It's a really easy configuration to maintain, support and troubleshoot.

Something that could be done is an HTTP reverse proxy for all the services, with the substitution, but the SSL offloading could be done on the Load Balancers.

[BjoernT]

@cloudnull @odyssey4me With configurable I mean we would have a central switch in the user_variables to simply switch the protocol per endpoint type. Right now I would have to go into various endpoint.yml's to manually override that for pretty much each openstack component.

Regarding the webserver choice, I have nothing against using Apache, although I prefer full SSL support from the client to the openstack nodes. That's more a compliance necessity which will hit us with big ticket installations due to PCI/HIPAA requirements.

Speaking of the hostnames, I meant only the external_vip_address and internal_vip_address, nothing else. Those two settings have impact on SSL communication, anything else can stay the way it is IMHO. Once we set the internal_vip_address and external_vip_address to DNS names it would be good if the add the host entries too (Probably we add an IP check on those variables and don't add host entries etc). Or we leave it up to the OPS team to add the host entries. Using DNS entries in both variables should work already today right ? In the long term we want to use our own external domain and add a subdomain for each client/installation