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.
--- 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.
--- IP address can change dynamically, at least after a machine reboot.

Related tickets:

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?

What are use cases?

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.)

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!

Petr^2 Spacek

Freeipa-devel mailing list

Reply via email to