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. >
Description: This is a digitally signed message part
_______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel