It will be shown unencrypted if you run in debug mode. Other than that, it should be fine.
Trevor On Fri, May 20, 2016 at 3:27 PM, Corey Osman <[email protected]> wrote: > 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 >>> [email protected] >>> >>> On Wed, Apr 20, 2016 at 10:52 AM, Ian Oberst <[email protected]> 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 [email protected]. >>>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/7f9f464d-4de8-4470-9caa-46a5bdca2800%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/7f9f464d-4de8-4470-9caa-46a5bdca2800%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoV7Xmh3ERLU%2BEmXktNYVWb1gE5huaQH0kgwXUjz79NqnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
