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

[Dmitri Pal]

On 09/14/2013 01:27 PM, Simo Sorce wrote:
> 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.
>
Please open.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/