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] <javascript:> > > On Wed, Apr 20, 2016 at 10:52 AM, Ian Oberst <[email protected] > <javascript:>> 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] <javascript:>. >> 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/dd689121-f83a-4c81-8f7b-fe675b31541f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
