New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for securely storing credentials via 'ProtectedData' Module #378

Open
vScripter opened this Issue Apr 29, 2015 · 5 comments

Comments

5 participants
@vScripter
Collaborator

vScripter commented Apr 29, 2015

Add in support/use ProtectedData module to better secure and handle stored credentials used for execution/reporting.

The ProtectedData module was created and is actively maintained by Dave Wyatt

@vScripter vScripter added this to the 7.0 milestone Apr 29, 2015

@vScripter vScripter changed the title from Add support for securely storing credentials via 'ProtectedDdata' Module to Add support for securely storing credentials via 'ProtectedData' Module Apr 29, 2015

@vScripter vScripter added ready enhancements and removed ready labels Apr 29, 2015

@alanrenouf

This comment has been minimized.

Show comment
Hide comment
@alanrenouf

alanrenouf Apr 30, 2015

Owner

Or maybe we should just say people have to use New-VICredentialStoreItem to store creds for this script?

Owner

alanrenouf commented Apr 30, 2015

Or maybe we should just say people have to use New-VICredentialStoreItem to store creds for this script?

@vScripter

This comment has been minimized.

Show comment
Hide comment
@vScripter

vScripter Apr 30, 2015

Collaborator

That is also an option. Does it support persistence across user logins on the same system?

I was thinking more along the lines of supporting an encrypted, hard coded password, that would require a separate key/cert to decrypt it, upon execution, which avoids using the .NET Data Protection API, which isn't versatile if you have the report running on several servers in a large and/or geographically disbursed environment.

PowerShell v5 natively supports almost all of the features of the ProtectedData module.

Either way, I was mainly thinking of a more efficient and secure way to maintain credentials; it very well may be the case that New-VICredentialStoreItem is a better way to go (not to mention it's native PowerCLI)

Collaborator

vScripter commented Apr 30, 2015

That is also an option. Does it support persistence across user logins on the same system?

I was thinking more along the lines of supporting an encrypted, hard coded password, that would require a separate key/cert to decrypt it, upon execution, which avoids using the .NET Data Protection API, which isn't versatile if you have the report running on several servers in a large and/or geographically disbursed environment.

PowerShell v5 natively supports almost all of the features of the ProtectedData module.

Either way, I was mainly thinking of a more efficient and secure way to maintain credentials; it very well may be the case that New-VICredentialStoreItem is a better way to go (not to mention it's native PowerCLI)

@monahancj

This comment has been minimized.

Show comment
Hide comment
@monahancj

monahancj May 8, 2015

Contributor

We use the credentials feature of Task Scheduler that's been part of Task
Scheduler since it came out (I think). I guess I'm not seeing the use
case. Doing it any other way else seems unnecessarily complicated.

On Wed, Apr 29, 2015 at 11:09 PM, Kevin Kirkpatrick <
notifications@github.com> wrote:

That is also an option. Does it support persistence across user logins on
the same system?

I was thinking more along the lines of supporting an encrypted, hard coded
password, that would require a separate key/cert to decrypt it, upon
execution, which avoids using the .NET Data Protection API, which isn't
versatile if you have the report running on several servers in a large
and/or geographically disbursed environment.

PowerShell v5 natively supports almost all of the features of the
ProtectedData module.

Either way, I was mainly thinking of a more efficient and secure way to
maintain credentials; it very well may be the case that
New-VICredentialStoreItem is a better way to go (not to mention it's
native PowerCLI)


Reply to this email directly or view it on GitHub
#378 (comment)
.

Contributor

monahancj commented May 8, 2015

We use the credentials feature of Task Scheduler that's been part of Task
Scheduler since it came out (I think). I guess I'm not seeing the use
case. Doing it any other way else seems unnecessarily complicated.

On Wed, Apr 29, 2015 at 11:09 PM, Kevin Kirkpatrick <
notifications@github.com> wrote:

That is also an option. Does it support persistence across user logins on
the same system?

I was thinking more along the lines of supporting an encrypted, hard coded
password, that would require a separate key/cert to decrypt it, upon
execution, which avoids using the .NET Data Protection API, which isn't
versatile if you have the report running on several servers in a large
and/or geographically disbursed environment.

PowerShell v5 natively supports almost all of the features of the
ProtectedData module.

Either way, I was mainly thinking of a more efficient and secure way to
maintain credentials; it very well may be the case that
New-VICredentialStoreItem is a better way to go (not to mention it's
native PowerCLI)


Reply to this email directly or view it on GitHub
#378 (comment)
.

@Sneddo

This comment has been minimized.

Show comment
Hide comment
@Sneddo

Sneddo May 8, 2015

Collaborator

This would not change the existing functionality, but extend it to give more flexibility.

I guess the simplest use case to highlight the need for this would be if you had an account that only had read-only rights to vCenter (e.g. your "every day" account that you use on your workstation), and wanted to use a privileged account to read event logs from vCenter.

Collaborator

Sneddo commented May 8, 2015

This would not change the existing functionality, but extend it to give more flexibility.

I guess the simplest use case to highlight the need for this would be if you had an account that only had read-only rights to vCenter (e.g. your "every day" account that you use on your workstation), and wanted to use a privileged account to read event logs from vCenter.

@rnelson0

This comment has been minimized.

Show comment
Hide comment
@rnelson0

rnelson0 Sep 8, 2016

Contributor

I submitted #485 as a method to do this. I wasn't aware of New-VICredentialStoreItem, or of the Task Scheduler credentials feature. Whatever the solution is, it should be integrated in the "Adjusting connection Information" section at http://www.virtu-al.net/vcheck-pluginsheaders/vcheck/

Contributor

rnelson0 commented Sep 8, 2016

I submitted #485 as a method to do this. I wasn't aware of New-VICredentialStoreItem, or of the Task Scheduler credentials feature. Whatever the solution is, it should be integrated in the "Adjusting connection Information" section at http://www.virtu-al.net/vcheck-pluginsheaders/vcheck/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment