puppet provider password decryption?

[Jason McMahan]

Good day,

I wanted to toss this out there to see if anyone has tried this.

Could i perform a hiera lookup from within a custom puppet provider?

My thinking is to lookup an encrypted password, then use the lookup to decrypt and pass the username and password to a powershell that i need to execute within that provider.

Thoughts?

[Ryan Murphy]

I use eyaml for encrypted data in hiera.

https://www.olindata.com/en/blog/2015/02/eyaml-hiera-data-encryption

[jcbollinger]

First, everything interesting that providers do, they do on the target node.  Hiera data, on the other hand, live primarily on the node hosting the catalog builder.  Those are the same node when applying catalogs via 'puppet apply', but they are usually different nodes when applying catalogs via 'puppet agent'.  It's unclear which is your scenario, but if you're running the agent (== running Puppet as a service) then your provider likely cannot perform hiera lookups because the data are not available to it in the first place.

Second, even if the data were available, if they include both key and encrypted data then you gain very little security, because anyone who can obtain the data can also obtain the key.  Same if you transmit the encryption key inside your catalogs or hard-code it into your provider implementation.  Encryption just isn't very secure overall without additional secure measures for key storage and / or key generation and exchange.

Overall, I don't see much to be gained.  Catalog data are already encrypted on the wire between master and agent (SSL / TLS), with both parties authenticating.  This is pretty good protection against data being stolen in transit.  As for protecting sensitive data once it reaches target nodes, however, your first and best and perhaps only real protection is the authentication and access control measures of that machine. If you are unwilling to trust those, then only solution is to altogether avoid giving the node sensitive data.

John

[Jason McMahan]

Thank you both for your reply.

The scenario i have is as follows.

I need to create/destroy/modify active directory group.

There is a winad module, once i was able to get it working to create the group it was doing it under my user context. 

To have it run properly i would need to supply it a credential.

Unless i am missing it i would need to execute powershell with username and password pass it to get-credential and populate a variable.

Then take a variable pass that to -credential and it would create the group as i need or destroy. 

I am grateful for any help suggestions.

Thank you again.

Jason

On Tuesday, April 10, 2018 at 12:41:27 PM UTC-5, Jason McMahan wrote:

[jcbollinger]

On Wednesday, April 11, 2018 at 2:02:52 PM UTC-5, Jason McMahan wrote:

Thank you both for your reply.

The scenario i have is as follows.

I need to create/destroy/modify active directory group.

There is a winad module, once i was able to get it working to create the group it was doing it under my user context. 

To have it run properly i would need to supply it a credential.

Unless i am missing it i would need to execute powershell with username and password pass it to get-credential and populate a variable.

Then take a variable pass that to -credential and it would create the group as i need or destroy. 

I am grateful for any help suggestions.

In general, running the Puppet 'agent' or 'apply' commands in an ordinary user context is of limited utility for exactly the sort of reason you've run into: Puppet then has insufficient privilege to manage a lot of the things that one typically wants to manage.  The usual and recommended way to address that is to run the whole Puppet process in a context that has sufficient privilege to perform the tasks it must perform.  On Windows, for example, the Puppet agent can be set up to run as a service running under the SYSTEM account.

The SYSTEM account in particular is probably inappropriate if you want to manage institutional AD, but here we come to the crux of the matter: you're trying to empower a principal (whatever user is running Puppet) to impersonate a different principal so as to exercise that second principal's privileges.  From a security perspective, whether the first principal should have authority to do that ought to be a question only of the identities of the principals involved.  If such authority exists in your case then one manifestation is that it is unnecessary to protect the second principal's credentials from the first principal, as they are authorized to have and use them.

On the other hand, if it is not the case that the principal on whose authority Puppet runs should be empowered to impersonate the second principal in general, then it is a violation of security protocol to allow them to do so under any circumstances.  You should then avoid providing the second's credentials at all.  Instead, you might set up a for-purpose service or application that the first principal is permitted to use to achieve the objective, without impersonating a different principal, whether directly or indirectly.

John