It sounds like the multitenancy configuration is not an option currently.  What about running separate FreeIPA instances per client in containers (Docker)?  Each client could have their own set of servers per DC and you could still keep your proposed DNS structure.  Regarding FreeIPA server replication, I would stick with no more than 2 replica's per DC.  Running 4 per DC would push you to 16 FreeIPA instances per realm for the enterprise, depending on the number of clients/realms you need, you could end up managing 100's of instances.  Probably not what you want to do. 

-Mike

-----Original Message-----
From: "Michael S. Moody"
Sent: Mar 31, 2016 6:22 PM
To: freeipa-users@redhat.com, jeff hallyburton
Subject: [Freeipa-users] FreeIPA Deployment Proposal (request for recommendations)

Hello FreeIPA Devs/Mailing List,


We use FreeIPA to great success in several places, but we want to roll it out for us. Thus, we want to ask about best practices for the type of deployment we’re planning. First, FreeIPA is truly awesome, and the glue that holds all these pieces together is really a phenomenal achievement. We want to set up our FreeIPA deployment according to best practices.


As it stands today, we want to implement FreeIPA to take over the authentication duties and DNS duties of an infrastructure which we are in the process of rebuilding from scratch, so we’re not worried about retroactively making things work on older systems. This is an important point for us, basically consider that we’re doing everything from scratch, and re-basing off of CentOS 7. (Apologies in advance for the wall-of-text).


Who we are:

We are a Managed Services Provider with multiple clients, and manage our clients’ systems end-to-end. This enables us to have full control over the infrastructure.


Topology:

We currently have 3 (where we’ll place FreeIPA at least) datacenter facilities in the USA, and are bringing a 4th DC online in the EU shortly. These datacenters are protected via enterprise-grade hardware firewalls, and we have VPNs across the DCs to allow our various infrastructure pieces to communicate on internal subnets vs across the public WAN. Additionally, we advertise our own IP addresses via BGP. We also have (bind-based) DNS in each DC, but primarily for external purposes.


Private:

US-EAST: 172.29.0.0/19

US-WEST: 172.29.32.0/19

US-SOUTH: 172.29.64.0/19

EU-WEST: 172.29.96.0/19


Public:

US-EAST: 1.1.1.0/24

US-WEST: 1.1.2.0/24

US-SOUTH: 1.1.3.0/24

EU-WEST: 1.1.4.0/24


Goals:

  1. We want to have centralized authentication for our entire infrastructure.

  2. We want the authentication to be highly available (FreeIPA replicas)

  3. We want to have a drastically improved DNS system that handles both external (domain names) and internal (systems).

  4. We want that DNS system to also be highly available (FreeIPA replicas with bind-ldap as the backend seems to be the best way)

  5. We want to use our own SSL certificates if at all possible (wildcard certificates, letsencrypt, etc)

  6. We would like to be multi-tenant with domains/realms/whatever so that CLIENT1 can have their authentication of their systems centralized through our FreeIPA. Similar for CLIENT2, CLIENT3, etc. The clients don’t care, so how this is set up is up to us/best practices.

  7. As part of the multi-tenancy, we don’t want all users to be able to see all users. To be more clear, we want to have 1 FreeIPA infrastructure that can use our domain (let’s call it GREATMSP.COM), and have systems for CLIENT1 as part of CLIENT1.GREATMSP.COM or whatever the best way is. We also want where if they login to FreeIPA, they’ll only see their users/systems.

  8. If we use GREATMSP.COM as the domain, we of course want to still have all of our normal DNS records (MX, NS, etc, etc). We’re perfectly good with (and prefer) using the more robust FreeIPA as nameservers for our root domain name.

  9. We would like users to be able to self manage (FreeIPA web ui)

  10. We plan to have at least 2 x FreeIPA servers in each DC, with the more likely scenario being 4 x in each DC.

  11. We want to use DNSSEC wherever possible. Because security.

  12. Ideally, can we use the FreeIPA servers as NTP servers?


Questions:

  1. What services/ports can we safely expose to the outside world, and what services/ports NEED to be exposed to the outside world for this to work effectively with systems in multiple DCs?

  2. As part of the above, should authentication only be done across the VPN?

  3. Can we safely use our main domain name (GREATMSP.COM) as the domain for FreeIPA? As part of this, we have say, TICKETING.GREATMSP.COM (a web app which will remain the same), and for systems, we might have SSH01.US-EAST.PRODUCTION.GREATMSP.COM (or perhaps SSH01.DC.US-EAST.PRODUCTION.GREATMSP.COM for the internal, and SSH01.US-EAST.PRODUCTION.GREATMSP.COM for the external).

  4. Can we use this as a more generalized DNS system for other customer domains as opposed to our current bind system? If so, is it as simple as registering all of the FreeIPA servers (replicas) as NS servers with the registrar?

  5. Since we want to be effectively multi-tenant, can we make it so that all authentication from the CLIENT1 infrastructure uses external addresses vs us needing to open holes into our FreeIPA infrastructure via VPN? How safe is/can this be?

  6. We see some notes about CA-Less being somewhat broken. Is this true?


(Things we don’t really need/want to do):

  1. Have each Client have their own SSL certs (complete non issue)


Things we don’t know we don’t know:

  1. Robustness?

  2. Security?

  3. Performance?

  4. Anything else we haven’t thought of?



Any help you can provide would be wonderful. We have attached a proposed diagram of what we're thinking of trying to accomplish.


Thanks in advance,

Michael


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to