Working on a new PowerShell module: ProtectedData

I'm working on a new module intended to make it easier to encrypt secret data, and share it among multiple users and computers in a secure fashion. It's not quite ready for "release" yet, but I've made it public on GitHub anyway, so I can start to get feedback early.

Check out my original blog post (link) for details. The GitHub repository is here.

2 thoughts on “Working on a new PowerShell module: ProtectedData

  1. Tore Groneng

    hi Dave,

    I have been thinking about this after I read your post. Good work by the way. I have 2 questions that has been bouncing around in my head:

    1. Would it have been easier to just use xJEA? With that I mean configuring an endpoint that would use the exportcli-xml cmdlet and host a "crendential store". A custom module would still be required, however the amount of code would be much less?
    2. Use SMA credential store (built-in). As with the first one, a custom module or script is required to retrieve the credentials from SMA

    Usually when dealing with these issues I find the biggest challenge is to store the credentials in a safe (encrypted) manner and being able to retreive those credentials at runtime. Of course you should consider the overall solution when credentials need to travel across the network, however it is less of an issue for intranet solution. Crossing network boundaries with credentials in clear text becomes a problem.

    I am not saying that your custom secure module is wrong. I am merely wondering if you considered one/all of those options and still chose to do a custom module?

    Cheers

    Tore

    1. Dave Wyatt Post author

      Hi Tore,

      I wrote the ProtectedData module to be general-purpose; it can encrypt anything, not just credentials / passwords. For allowing users to execute commands in an alternate, elevated context, constrained endpoints (and xJea) are definitely the way to go. That's the only way I know of to prevent the admin credentials from being exposed to the end-user.

      I'm not very familiar with SMA, but my understanding was that it's a product that requires System Center Orchestrator and/or Azure. If it has similar functionality to the ProtectedData module, then it might be preferable to use SMA so long as you have all of its dependencies covered.

Comments are closed.