On Fri, 2014-06-06 at 15:10 +0200, Jan Pazdziora wrote:
> On Fri, Jun 06, 2014 at 08:51:39AM -0400, Simo Sorce wrote:
> > 
> > Clearly puppet has root level access to the system so you do not (should
> > not ?) care much about preventing access to these systems, the aim is to
> > not inadvertently divulge secrets through manifests and nothing else.
> 
> And puppet logs. And forgetting the secrets around.
Right... A good reason to not store anything in puppet.

> 
> With puppet you do not have interactive (password) prompt available so
> everything including secrets needs to be pre-created and pre-populated
> before the puppet apply starts. Or, where possible, generated and
> immediatelly encrypted -- I find that approach very clever.
Thanks :)

>  But
> unfortunately it can only be used for the initial FreeIPA server
> installation, it seems -- in all the subsequent operations, we need to
> pass the existing matching credential.
Right... This is what I'm trying to work around. I only need this for
additional replicas. The single master case is basically *solved*. But
it's no fun to stop there...

> 
> I wonder if we could be able to pass the passwords to puppet via file
> descriptors from some invoking wrapper ...

See my comment on:
https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/
about an interactive password helper.

This could be useful for something when puppet-freeipa is being used
with other tools that insist on telling it the password... Functionally
the issues with the replicas don't dissapear. We have to pretend that
the password is still "forgotten" after initial install of first master.

> 

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to