[Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments

[Simo Sorce]

On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote:
> Hello list,
> 
> FreeIPA deployments in cloud environments do not work very well because 
> 'clouds' break some assumptions we made during FreeIPA's design.
> 
> We should fix it somehow :-)
> 
> === Problems ===
> - A machine has two host names in DNS:
> -- The first name is internal to the cloud and resolvable only from inside of 
> the cloud.
> --- This name should be used for communication inside cloud.
> --- E.g. 'ipa.cust1.cloud.'
> --- Internal name is mapped to internal IP address, see below.
> 
> -- The second name is external to the cloud and should be used for 
> communication between the Internet and cloud.
> --- E.g. 'ipa.example.com.'
> --- External name maps to external IP address, see below.
> 
> - A machine has two IP addresses:
> -- Internal, private IP address configured at the machine's interface
> --- Typically the only IP address known to the machine.
> --- E.g. 192.0.2.22
> --- IP address can change dynamically, at least after a machine reboot.
> 
> -- External, public IP address:
> --- Typically mapped to internal address at cloud boundary (NAT).
> --- E.g. 203.0.113.113
> --- IP address can change dynamically, at least after a machine reboot.
> 
> Related tickets:
> https://fedorahosted.org/freeipa/ticket/2648
> https://fedorahosted.org/freeipa/ticket/2715
> 
> The natural request is to add support for DNS views/split horizon DNS into 
> FreeIPA, so different names and IP addresses can be served to clients inside 
> and outside of the cloud.
> 
> Is it enough? What else should we change to make FreeIPA reliable in clouds?

I do not understand what's the use of views in this case.

Views are used when you want to assign different IP addresses to the
same name depending on where the query comes from.

But here we have different names pointing to different addresses and the
machine actually know nothing about the external name/IP.

So what is the point of a view here ?

>From the FreeIPA pov, if you use it for infrastructure you should just
care about internal names.
For the rare case where you want to have some client use the external
name to access a machine then what we need to do is to make it easy (it
is possible but not exposed now) to assign aliases to hosts so that you
get an alias for each host/ and other service principals in the kerberos
database and you get alternate names in the x509 certs.
But I still do not see any issues with DNS, except for the fact that the
network manager service of the cloud provider needs to be able to
maintain the DNS records according to how it assigns IPs to names.

> What are use cases?
> 
> Do we want to support clients *outside* of the cloud connecting to FreeIPA 
> servers *inside* of the cloud?

I think we should give the option, see above.

> What about PKI certificates? Should we put two names to each certificate? What 
> we should do after host name change? (I do not have enough information when 
> the host name changes.)

A change in host name will require a new certificate. But if the name is
stable then we just need to populate certs with aliases

> What about Kerberos? How it will play with host name change? How should we 
> handle the fact that internal and external names are different? Should we use 
> some sort of referral mechanism?

Uhmm a referral may also work in future, but we could simply uses
aliases, not all applications may work properly (some insist on a
specific name, but a lot of apps these days can be configured to use
just the service name and then accept tickets as long as they can be
decrypted (key is the same).

> Cloud users, please speak now :-) Opinions are more than welcome!

Indeed, if you see any wrong assumption in here, it would be *really*
nice to have a heads up.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York