[Freeipa-devel] Proposal: reverse stance on installing CA on new masters

[Fraser Tweedale]

On Thu, Apr 09, 2015 at 10:58:35PM -0400, Simo Sorce wrote:
> On Fri, 2015-04-10 at 10:44 +1000, Fraser Tweedale wrote:
> > On Thu, Apr 09, 2015 at 05:06:31PM -0400, Simo Sorce wrote:
> > > On Thu, 2015-04-09 at 16:52 -0400, Rob Crittenden wrote:
> > > > Simo Sorce wrote:
> > > > > On Thu, 2015-04-09 at 15:42 -0400, Rob Crittenden wrote:
> > > > >> Petr Vobornik wrote:
> > > > >>> On 04/09/2015 04:05 PM, Rob Crittenden wrote:
> > > > >>>> Right now when a new master is installed it is not configured with a CA
> > > > >>>> unless one passes in --setup-ca (or afterward runs ipa-ca-install).
> > > > >>>>
> > > > >>>> Over and over we've seen people who have multiple masters and a single
> > > > >>>> CA, in some cases that CA machine is gone, leaving the realm with no CA
> > > > >>>> at all.
> > > > >>>>
> > > > >>>> I think this is due to the fact that CA replicas are not created by
> > > > >>>> default and the users are not aware of the implications of a single
> > > > >>>> point-of-failure since things otherwise seem to be working.
> > > > >>>>
> > > > >>>> So perhaps the default should be to install a CA unless the user
> > > > >>>> requests one not be installed. A related task may be to create an
> > > > >>>> uninstaller for just the CA.
> > > > >>>>
> > > > >>>> rob
> > > > >>>>
> > > > >>>
> > > > >>> From a general perspective:
> > > > >>>
> > > > >>> When I hear "replica" it evokes a "clone", something equal/identical.
> > > > >>>
> > > > >>> Based on this, the expected behavior for me would be that:
> > > > >>>
> > > > >>> - if master has DNS and CA, then the new replica would also have DNS and
> > > > >>> CA (without any configuration option needed).
> > > > >>> - if an optional service is missing then replica wouldn't have it as
> > > > >>> well by default
> > > > >>>
> > > > >>> This would required reverse options like: --no-dns.
> > > > >>
> > > > >> Pretty much exactly what I was thinking.
> > > > >>
> > > > >> For the option I think we should go with a more generic --ca, --dns,
> > > > >> with the default value matching what the remote master has configured.
> > > > >>
> > > > >> But that's bike shedding.
> > > > >>
> > > > >> The real question is, what do others think? Is this worth filing a
> > > > >> ticket for? It would be a subtle but significant change. This might tie
> > > > >> in nicely with planned topology management too.
> > > > > 
> > > > > I think I would like to see questions in interactive mode, but not force
> > > > > CA and DNS to be installed just because the other replica has them.
> > > > > 
> > > > > The replica originating machines has more to do with topology (what
> > > > > master you want to replicate off) then features.
> > > > > 
> > > > > So if you are doing an interactive install and the remote replica has CA
> > > > > and DNS features, it may be nice to ask: do you want to setup CA too ?
> > > > > Do you want to setup DNS too ?
> > > > > But not do it by default w/o positive confirmation.
> > > > > Esp for DNS it makes little sense as you need a change in DHCP/other
> > > > > infra for it to be of any use and all data is in LDAP anyway
> > > > > The CA case is a little bit more critical as you noted, but I think
> > > > > nagging in interactive is probably good enough.
> > > > 
> > > > That's why I suggested this be tied to the topology plugin, so the user
> > > > has a chance to massage things afterward in an easy manner.
> > > > 
> > > > A less obtrusive suggestion would be to be to try to count the number of
> > > > CAs and spit out a scary warning if it is just one.
> > > >
> > "Nagging in interactive", "scary warning if < 2 CAs" are probably
> > good enough to avoid the horror stories, but is it good enough UX
> > to require user intervention to avoid the loss of CA on losing a
> > single replica?
> 
> I think it is better than the current situation.
>  
> > > Maybe force CA on if there is only one CA ? (Ie first 2 servers get to
> > > be CAs) then a new CA is force installed only if one of the 2 is
> > > killed ?
> > > 
> > > Simo.
> > > 
> > We would only need this special case if there is a problem with
> > having a CA clone for each replica, right?  Is there a problem?
> 
> Private CA key exposed on additional servers.
>
The main reason we are having this discussion is because people have
lost the private keys.  Almost everything else is recoverable,
except certificates that were issued using Dogtag directly (if any)
or KRA data (Which is the Vault backend where secrets are stored).

> Added replication load.
> Added CPU/Memory load (dogtag is not exactly lightweight).
> 
Granted, but is it so bad?  (Genuine question; I really don't know
much yet about replication and costs thereof). They already have all
the things running on the first host, and presumably will be
deploying replica on similar hardware.

Cheers,
Fraser

> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
>