Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On Fri, Sep 13, 2013 at 09:08:10AM -0400, Simo Sorce wrote: 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. Which can well be useful in cloud -- you might want to access the other machine of your setup using its internal IP address because it's cheaper than going through the external interface. But here we have different names pointing to different addresses and the machine actually know nothing about the external name/IP. Well, the fact that a name does or does not exist is also a use-case for views. There probably is little point presenting the internal names to the external world. From the FreeIPA pov, if you use it for infrastructure you should just care about internal names. Isn't it quite the oposite in cloud? The individual machines are disposable often and all that matters is that there is a machine which is able to provide a service, on some well-known stable public host name. Which physical VM serves that service can change rapidly. A one VM providing the service can change to five with some HA proxy in front of them. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On 15.9.2013 20:19, Dmitri Pal wrote: 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. You are right, the scenario described by me doesn't require views. Please see reply from James in another part of this thread - his setup has shared host name (internal = external) but different IP addresses for internal and external usage. The question is if DNS is the right layer to solve the problem. Some oddities like this could be solved on IP routing level: I.e. use 'external'/public IP address everywhere and route packets with this 'external IP' to the right part of the internal network. Solution on routing layer can be technically feasible, but it doesn't mean that it is politically acceptable. People usually don't want to touch routing unless absolutely necessary :-) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On Mon, 2013-09-16 at 09:31 +0200, Petr Spacek wrote: You are right, the scenario described by me doesn't require views. Please see reply from James in another part of this thread - his setup has shared host name (internal = external) but different IP addresses for internal and external usage. The question is if DNS is the right layer to solve the problem. Yep. See below. Some oddities like this could be solved on IP routing level: I.e. use 'external'/public IP address everywhere and route packets with this 'external IP' to the right part of the internal network. Solution on routing layer can be technically feasible, but it doesn't mean that it is politically acceptable. People usually don't want to touch routing unless absolutely necessary :-) FWIW, I completely agree, although I do not having a problem with the routing solution, in certain setups it can add much more complexity which may not be required or even possible to do. Eg: conntrackd setups could get hairy or impossible. Let's do this in DNS. James PS: If anyone wants to meet to talk about this, I'm at Linuxcon New Orleans this week if I can be of any help. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
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/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On Fri, Sep 13, 2013 at 4:26 AM, Petr Spacek pspa...@redhat.com wrote: Hello list, Hey 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 :-) Agreed ! === 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. In my situation, the IP's are always constant. -- 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. I've asked about split view DNS support before. It would be extremely valuable! Is it enough? What else should we change to make FreeIPA reliable in clouds? What are use cases? As described above, my particular use case is one machine with one consistent hostname, but with multiple IP addresses. Internally the VM sees itself as say 10.10.10.1, but externally it might have one or more different addresses that are used to NAT directly to it for example. Do we want to support clients *outside* of the cloud connecting to FreeIPA servers *inside* of the cloud? 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.) I never have any issues about different host names. All are consistent. 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? Cloud users, please speak now :-) Opinions are more than welcome! Some comments are given above. Please keep me in the loop. Once this is cooking, I'd love to add puppet-ipa support to match. https://github.com/purpleidea/puppet-ipa I'm happy to answer any questions you have. -- Petr^2 Spacek Thanks, James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
