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

[Dmitri Pal]

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/