I have been in this same situation before and used node_encrypt to do the job.
https://github.com/binford2k/binford2k-node_encrypt You can do the following. 1. encrypt hiera data with hiera-eyaml 2. encrypt parameter or other item during compilation using node_encrypt as the eyaml encrypted data is decrypted during compilation 3. create an exec resource 4. set an env variable with the encrypted data 5. inline the decryption of that variable in the command using puppet node decrypt exec { 'set service passphrase': command => 'some-service --set-passphrase="$(puppet node decrypt --env SECRET)"', path => '/opt/puppetlabs/bin:/usr/bin', environment => "SECRET=${node_encrypt('and your father smelt of elderberries')}", } The outcome of this is that the secret is encrypted throughout the entire lifecycle of the code, catalog and on the node itself. The only time the secret is unencrypted is during execution of the command which should only last a few seconds. Which to my knowledge does not get recorded anywhere. You could inline this same strategy in a custom provider as well. Ideally we should get the powershell provider to use node_encrypt as an option. Corey On Wednesday, April 20, 2016 at 9:37:32 AM UTC-7, Ian Oberst wrote: > > Possibly. I'm assuming that you mean an encrypted one? There would be > quite a bit of overhead there, as I'd have to generate the encrypted > PSCredential for each individual node. That makes using an encrypted hiera > backend to store the credentials much more gross since I can't store a > single credential for each cluster of nodes that use it. > > I should probably add that I have come up with a working method that I > think works. However, I wasn't sure if this was a method that lined up with > the longer-term direction that general community wanted. Here's what I have > at the moment: > > I wrote a Puppet function that, given an Authenticode certificate, signs > the Powershell script (or anything you pass it, really) on the Puppet > master before adding it to the catalog. I then forked the Powershell > provider and changed it so that instead of invoking scripts via STDIN it > instead invokes scripts using the "-file" parameters, as well as settings > the execution policy to only allow signed scripts. Once I have my > certificate in place on a node I can then save to disk, temporarily, > powershell scripts and execute them without worrying about them being > altered (which was the given reason for the current Powershell provider > passing the script via STDIN). > > I also modified the new provider to search the catalog for a custom > resource type which essentially holds parameters to pass to the Powershell > script. If it finds them it adds them to the command line call to > Powershell. This allows me to pass credentials as a parameter, which avoids > having them written to disk as part of the Powershell script or by some > other means. Finally I also had the provider temporarily bump the log level > and override the parent logging so that parameters are *not* shown in the > event log or debug output. > > So far it seems to work well, issues with securing the catalog itself not > withstanding. Again, I wanted to try see what the larger community felt was > a good direction to take this rather then continue to head in some other > direction. It may be that when the Powershell Manager finally gets released > that putting credentials directly into templates won't be an issue any more. > > On Wednesday, April 20, 2016 at 8:49:19 AM UTC-7, Rob Nelson wrote: >> >> Can you pass a $PSCredential down, maybe as a File resource that the >> script can rely on? The scripts may need modified per >> https://technet.microsoft.com/en-us/magazine/ff714574.aspx >> >> >> Rob Nelson >> rnel...@gmail.com >> >> On Wed, Apr 20, 2016 at 10:52 AM, Ian Oberst <ian.o...@gmail.com> wrote: >> >>> I've had a number of conversations with various Puppet folks about this >>> and it remains a bit of a sticky issue, namely *how do we safely handle >>> powershell scripts where we need to pass credentials or other sensitive >>> information to Powershell?* >>> >>> The scenario here is that we have a situation where we need to give >>> Powershell some credentials to perform some sort of work on the system. Due >>> to restrictions we have to pass these credentials via Puppet in some >>> fashion, e.g. we can't or don't have access to a key manager that >>> Powershell can talk to directly, meaning that Puppet is the only route of >>> providing the secrets to the node. (I do understand there are other >>> issues here as well, such as getting secrets securely passed in the >>> catalog, but I'm setting that aside for now.) >>> >>> >>> Recent incarnations of the Powershell provider all write a temp file to >>> disk that contains the powershell code to be invoked. This means that if I >>> have the credentials placed directly in the script (which generally seems >>> the route I have to take) that I'll have written them to disk. >>> Additionally, the exec module itself has logging that will log the command >>> out to both the event log and the Puppet report, which will expose >>> credentials. None of these outcomes are very good. >>> >>> >>> The approach I've tried to take is going the route of signed powershell >>> scripts so we can invoke them with command line parameters rather than >>> using stdin, which is the route the current Powershell provider takes. This >>> seems at the moment to side-step some of the above mentioned problems >>> depending on how you communicate those command line parameters to the >>> provider. However, I'd like to align with the longer-term strategy, if >>> possible, of how Powershell scripts are invoked within the Puppet supported >>> provider. >>> >>> >>> So...what's the best way of handling this? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Puppet Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to puppet-dev+...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-dev/5bd0c1ad-d53a-4135-872c-62cfe4463cf5%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/puppet-dev/5bd0c1ad-d53a-4135-872c-62cfe4463cf5%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/7f9f464d-4de8-4470-9caa-46a5bdca2800%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
