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? Do we need several? One for Kerberos part another for PKI? May be more than that? For client checks may be?
-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
