PoSH Article of the Week! – Secure Credential Storage

While glancing over at PoSH today (the tiny turtle) I was inspired to do a bit of thinking and talking about using PoSH. Specifically the VI Toolkit, it really wouldn’t be blog worth otherwise would it? What I got thinking on, and what someone on irc clued me into, was storing credentials.

Why store credentials?

Well, the beauty of automation is that you don’t have to be there for it to happen. I mean really, your sprinklers go off without intervention, why shouldn’t your scripts? The conflict come is, is that Virtual Center requires authentication, and based on that authentication, you are granted some permissions and such. Storing these credentials is what makes the hands off automation happen. After all, do you really want to turn your sprinklers on each time?

Storing Credentials

This is the part of the post where we get into the code, so if you are faint of heart, or allergic to chicken teriyaki, you can move along now. Still with us? Great!

Built into the VMware VI ToolKit (for Windows) Version 1.5 are a few cmdlets that make this really really simple:

• New-VICredentialStoreItem
• Get-VICredentialStoreItem
• Remove-VICredentialStoreItem

Rather self explanatory, no? Let us glance at what they look like in use:

New-VICredentialStoreItem

New-VICredentialStoreItem -host ‘vCenter.professionalvmware.com’ -user ‘marcus’ -password ‘garvey’ -file c:\test

That is all one line, and what that basically does is create an XML file representing a credential store, with your encrypted password, like this:

<?xml version="1.0" encoding="UTF-8"?>
<viCredentials>
  <version>1.0</version>
  <passwordEntry>
    <host>vCenter.professionalvmware.com</host>
    <username>marcus</username>
    <password>omitted</password>
  </passwordEntry>
</viCredentials>

Cleared out the <password></password> area for space. It should also be noted here, that C:\ is likely not the best place to be storing these, and that they’re secured by NTFS file permissions, so use whatever security policies your organization dictates for this function (if they allow this at all). This is all well and good, how do we use them now?

Get-VICredentialStoreItem

Well, who didn’t see this cmdlet coming next? I mean 1/2 the page up I foreshadowed it quite heavily. As you can guess, using this cmdlet is not all that difficult, but we’ll show you how to use it anyways:

[VI Toolkit] C:\> $creds = Get-VICredentialStoreItem -file c:\test
[VI Toolkit] C:\> $creds | fl *

Host     : vCenter.professionalvmware.com
User     : marcus
Password : garvey
File     : c:\test

Cool, so we opened our credential store, and stored it in a variable, and as we can see that variable has a few properties to it, so lets use these to connect to a vCenter:

[VI Toolkit] C:\> connect-viserver -Server $creds.Host -User $creds.User -Password $creds.Password

Good stuff, in fact, excellent stuff. Considering, you can use this beyond storing just vCenter/ESX credentials, anything that requires a user/pass/hostname can be stored in this manner, and used again within your VI ToolKit scripts.

Now that we have all of this excellence, we’ll take a look at making it go away once your security guys catch wind of what you’ve been up to.

Remove-VICredentialStoreItem

Now, the foreshadowing and the lead in, if you couldn’t guess this title… no bacon and pancakes for you.

Looking at the get-help for Remove-VICredentialStoreItem, there are a number of ways you can remove said credential stores, you can specify the file, like we did in the past two examples, or, you can do like we do in this one, and use the pipeline:

[VI Toolkit] C:\> $creds | Remove-VICredentialStoreItem

Confirm
Are you sure you want to perform this action?
Performing operation "Remove-VICredentialStoreItem" on Target "Remove credential store item for
host ‘vCenter.professionalvmware.com’ and username ‘marcus’?".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Of course the answer is [Y]es, we want to do this, and if you want to actually turn the confirmation off, you can specify the “-confirm:$false” flag.

This of course brings us to the grand conclusion of this post. If you found this useful, please consider subscribing, and telling a friend (or three), if not, well… don’t tell anyone. If you have questions or comments, ping me on twitter, or via the comments.