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

[Simo Sorce]

On Fri, 2013-09-13 at 14:26 -0400, Dmitri Pal wrote:
> On 09/13/2013 09:08 AM, Simo Sorce wrote:
> > 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.
> >
> Do we have an RFE about aliases?

We should have one for kerberos, the LDAP/kdb part is already capable of
supporting aliases.

> Do we need several? One for Kerberos part another for PKI? May be more
> than that? For client checks may be?

We should have a separate one for x509 certs, yes.

Simo.

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