Use Provider Hostname instead of IP Address


#1

One of the issues that’s coming up more and more lately is wanting to use the Provider’s hostname to build connections instead of the IP address.

Why is this important? Specifically for Openstack (but, I suspect over time, this is going to affect all providers), there’s a strong desire to secure the AMQP server communication with SSL. It’s standard practice to build SSL certificates with Hostnames as the CN instead of the IP address. However, if the SSL cert is built with the Hostname, and we connect to the Provider using the IP address, the SSL cert is rejected because the URL and the CN don’t match. Apparently, the name matching is done before DN resolution.

In addition to just AMQP over SSL, several people have asked about the general Openstack API over SSL. This would also be impacted by our requirement to connect via IP Address.

I know that @Fryguy, @jrafanie, and possibly @bdunne have mentioned some historical reason for avoiding building provider connections with hostname. But, I can’t remember what that reason is.

So, I’d like this to serve as the one place I can point people who ask: Why can’t I do this?


#2

This is very relevant to a project that I’m on. We’re going to have a fully HA OpenStack environment with clustered AMQP nodes. I assume the IP address in the cert needs to be the VIP address in that case?


#3

On more investigation I’m guessing that we could use the Subject Alternative Name (SAN) within the cert: (http://en.wikipedia.org/wiki/SubjectAltName) to encode our IP address, and leave the CN as the FQDN.


#4

This alludes to another issue (that’s actually in current development right now), which is to allow a single provider to have multiple different connection points.

Take Openstack for instance: Openstack has both Keystone and AMQP connections that ManageIQ cares about. Luckily, Keystone handles the rest of the service connections for us, so we don’t need to bother with recording those individually. But, many have expressed the need to have separate endpoints for Keystone and AMQP.

We’re currently working on a solution for this in order to enable Microsoft’s SCVMM. But, the work done there will carry over to allowing other providers to have multiple endpoints.

So, the answer to your specific question is, “Most likely, but we definitely haven’t looked at HA AMQP yet at all.”

Hope that helps a little.


Update:

Heh, I just saw this from @pemcg: Multiple IP Addresses per provider … I’ll continue any further chats there. Thanks Pete!


Multiple IP Addresses per provider
#5

This is a really interesting idea that I haven’t explored at all. I remember looking at it briefly when trying to get the basic SSL with IP address cert stuff working originally. But, I didn’t dig any deeper.

This sounds like something that could be explored entirely without any code changes to ManageIQ. @pemcg, do you think you could take a look at this and see if it works? That would actually be a really nice stop-gap until we can support true hostname-based connections.


#6

To answer you statement - Yes, common name is the fully qualified hostname and the SAN (subject alternate name) can hold the ip address, or other fully qualified hostnames.

But lets not do this.
SSL wasn’t really made to work with ip addresses and while SAN with an IP addresses works, they are discouraged.

The correct solution is to use the hostname (or ip) as provided by the user. We can label the fields hostname to further encourage a user to enter the hostname rather than the ip address.

This will remove code, add cluster support, and support IPv6