[Freeipa-devel] Multi-master replication with puppet

[James]

On Fri, 2014-06-06 at 14:43 -0400, Simo Sorce wrote:
> On Fri, 2014-06-06 at 14:06 -0400, James wrote:
> > On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote:
 
> > > But let me ask a more important question, how do you distribute the
> > > public keys securely ? Is it puppet fetching them from each
> > > replica-to-be server and sending them to the first master server ?
> > Yes. That is one approach.
> 
> What did you have in mind ?
Actually, I'm good with this. If someone is unnecessarily paranoid I
could probably mangle this over SSH, but I'd like to avoid it. It still
requires distributing the SSH fingerprints over puppet...

> 
> > > It is also needed to actually store the DM password on the replica
> > > server itself in it's own cn=Directory Manager super user entry.
> > > Although I think we could send the hash for that.
> > This is what I was thinking... I'll need to know how to extract this,
> > send it (encrypted), and use it instead of --password
> 
> It might be greppable out of the dse.ldif file I think.
Can you help me with the specific commands for a Proof Of Concept?
I have found /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif
(attached)

How do I find a password in there? ( I couldn't see any )
How do I get that back in on the destination replica side once I find
it?
> > > 
> > > The simplest way to handle this (which I wanted to do for a while) is to
> > > pre-create the replica's LDAP principal and keys at replica-prepare time
> > > so we can start right away with GSSAPI authentication for the first
> > > replication and create agreements directly using GSSAPI auth. This would
> > > in turn simplify replication agreements creation as we won't need
> > > anymore to do the dance where we create the agreement with a plain text
> > > bind and then we need to convert the agreement to use GSSAPI.
> > 
> > This of course sounds fine to me. As long as it meets my criteria of not
> > needing the password, it should work. Is this an easy patch? IOW
> > something that I could test a build of within the next month at the
> > latest?
> 
> Well, you may not need a password (you do because you need to be DM on
> the replica to create replication agreements, but we can do some magic
> there and use ldapi as root I guess) but you'll need a keytab, which is
> a secret, just like a password and must not be exposed to anyone and
> anything just like the DM password. But that wouldn't be a problem, the
> keytab would be in the encrypted prepared file.

Great! Can you show to me how to do this part please?
* Generate this specific keytab
* Use it to complete the ipa-replica-install process

> 
> > > > I don't think there is any other need for the dm_password in
> > > > ipa-replica-install. Did I miss something?
> > > 
> > > See above, it needs the password to actually create the DM account at DS
> > > setup time. *also* the DM password is used to setup some parts of the
> > > dogtag CA so if any of your replica is also a CA clone you go straight
> > > back to needing the DM password.
> > Which I understand we could get around by passing around the (salted?)
> > hashed password, correct?
> 
> Not for the CA, unfortunately the CA requires the DM password in the
> clear.
I'll skip over doing the CA part for now... Sounds like I need to break
this into smaller challenges ;)

> > > Use the DM password to do everything as usual AND create the asymmetric
> > > keys in the replicas and *securely* transmit them to the master.
> > Keep in mind I'm only transmitting public keys, so it doesn't have to be
> > secure as long as I know verify the identity.
> 
> Bzzzzzzzzt. How do I know that "these are the public key I am looking
> for" if they are not transmitted securely ?
> If someone can sneak in an additional key or replace a public key in
> transit now it gets access to everything as soon you transmit the
> encrypted package!

Agreed. As discussed, I'm assuming that Puppet master has securely
authenticated it's individual puppet clients, and I am relying on that
trust to pass the public keys around.

> 
> > > Now wrap the current replica file (yes it is already encrypted, who
> > > cares), AND the DM password into a new envelope encrypted with your
> > > public keys.
> > > 
> > > Presto! Now you transfer the blob back to the replicas, and each replica
> > > can be scripted, and puppet has no passwords in its manifest.
> > 
> > This approach won't work because the first axiom is incorrect. To do
> > this, I would have to keep the dm_password around on each host with a
> > key that could be read and used by anyone with root. So effectively I
> > might as well store the password in puppet.
> 
> Look, at the moment there is no way around that, you have to have the DM
> password *or* an equivalent secret to install replicas, there is simply
> no way around that. You need to transport some form of credentials from
> the master ipa server to the replicas because the replicas need to
> authenticate to the master in order to be allowed to become replicas.
> It is as simple as that, whether it is the DM password, or a keytab, or
> something else.

I'd like to learn how to do this keytab solution for this scenario, or
perhaps use an OTP to authenticate... The OTP would be carried in the
pseudo-secure puppet channel.

> 
> > > > *symmetry*
> > > > 
> > > > It would be especially elegant and beneficial to FreeIPA and the
> > > > puppet module if the process of "peering" was symmetrical, that is to
> > > > say, similar for any host. If I could use ipa-server-install to setup
> > > > N hosts, and then run a secondary command to cause certain ones to
> > > > "join" this would make the process much more natural for puppet.
> > > 
> > > This is intrinsically not possible.
> > That is unfortunate. I could hack a version of this where by each host
> > runs the installer, but the ones that need to peer start by running:
> > 
> > ipa-server-install --uninstall && ipa-replica-install
> > 
> > but that is less elegant that the solution existing natively.
> 
> It is not about being inelegant, it is about being useless to me.

hehe, fair enough. I'll try and think if I can come up with a POC of why
it's needed. If it turns out to be a requirement, we can revisit it.

> 
> > > > In addition, this would ensure that the configuration management itself
> > > > is HA. Without this type of functionality, then if the first ipa
> > > > server isn't available, then config management will be blocked.
> > > 
> > > Yeah, chicken-egg issues of bootstrapping infrastructures. I currently
> > > do not see any way around this.
> > 
> > See my above idea for a dirty hack. (--uninstall)
> 
> install; uninstall; replica-install ... the first 2 steps are a no-op.
Agreed. It wasn't about trying to simplify down to a no-op, it was about
having a path in the state graph of going from installed => replica.
Currently you can do:

uninstalled => installed.
installed => uninstalled.
uninstalled => replica-ed.

But no:

installed => replica-ed.

So until that pathway is is possible, I will have to "fake it" by doing
an installed => uninstalled, so that I can turn an installed machine
into a replica.

Cheers,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140606/9f30898c/attachment.sig>