[Freeipa-devel] Multi-master replication with puppet

Fri Jun 6 22:22:33 UTC 2014

On 06/06/2014 03:57 PM, James wrote:
> 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)

grep nsslapd-rootpw /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif

The pwdhash command can be used to create a hashed password.

>
> 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
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140606/13c4b214/attachment.htm>