New vVol Replication PowerShell Cmdlets

Happy New Year everyone! Let’s work to make 2021 a better year.

In furtherance of that goal, I have put out a few new vVol-related PowerShell cmdlets! So baby steps I guess.

The following are the new cmdlets:

Basics:

  • Get-PfaVvolStorageArray

Replication:

  • Get-PfaVvolReplicationGroup
  • Get-PfaVvolReplicationGroupPartner
  • Get-PfaVvolFaultDomain

Storage Policy Management:

  • Build-PfaVvolStoragePolicyConfig
  • Edit-PfaVvolStoragePolicy
  • Get-PfaVvolStoragePolicy
  • New-PfaVvolStoragePolicy
  • Set-PfaVvolVmStoragePolicy

Now to walk through how to use them. This post will talk about the basics and the replication cmdlets. The next post will talk about the profile cmdlets.

Continue reading “New vVol Replication PowerShell Cmdlets”

Exporting/Importing a Certificate with the Pure1 PowerShell Module

When deployed on Windows, the Pure1 PowerShell Module takes advantage of Windows-based certificates in the user (or specified) certificate store. On Linux or MacOS, it uses RSA private key pairs.

To relocate authentication on a Non-Windows machine to another non-Windows machine, you just copy the private key from wherever it is to the target. For Windows though you need to export the cert (which has a private key) from the certificate store, then you can copy the file to wherever.

In the latest release of the Pure1 PowerShell module (1.4.3.1) there is a new feature to do that for you–or at least simplify the process of exporting the cert with the right settings.

Let’s walk through exporting and then importing the cert. In a future post I will go into some of the other enhancements in this release in more detail.

As always the repo is here (and release notes) and it is best installed/updated via the PowerShell Gallery:

install-module PureStorage.Pure1
or
update-module PureStorage.Pure1

https://github.com/PureStorage-OpenConnect/PureStorage.Pure1

Continue reading “Exporting/Importing a Certificate with the Pure1 PowerShell Module”

Using PowerShell with Tanzu and the Kubernetes API

Sounds like a silly thing, but we all have to start somewhere. Generally when I dig into something new, I like to start from a place I know well. So when it comes to using a new API, I like to use a tool I know how to use. Kubernetes–and its API is fairly new to me from a hands-on perspective. PowerShell, however, is not. I have decent handle on that. So seems to me a good place to start with the k8s API.

I don’t know if this is the best way, or even a good way, but it does work. And there is also this:

https://www.powershellgallery.com/packages/Microsoft.PowerShell.KubeCtl/0.0.3

But I am trying to learn authentication and the finer points of the API, so I like to start with first principles.

Create a Service Account

So the first step is to create a service account. So create a new file and then in that, enter in the following information, replacing the username and/or namespace with whatever you want:

vim newuseracct.yml

Then apply it:

Again using your favorite editor, create a new file:

vim newuser.yaml

This will apply the cluster admin role to that account. Replace the username, the namespace or even role as needed.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pscody
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: pscody
    namespace: kube-system

Now apply it:

kubectl apply -f newuser.yaml

Retrieve the Token

Once the account is created, you need the token. Run:

kubectl get serviceaccounts pscody -o yaml --namespace kube-system

Replacing the username and the namespace as needed.

Under the secrets, grab the name. In my case it is “pscody-token-s4lvz”.

Then run:

kubectl -n kube-system describe secret pscody-token-s4lvz

Copy everything in the token.

Get Server Address

Now you need to get the server address for the cluster where you created the user. So if you don’t know, look at the context via kubectl config get-contexts:

Then, run kubectl config view and pull the server address for the corresponding cluster, so for mine it is cody-dev so the address is https://10.21.202.237:6443

Connect with Invoke-RestMethod

Now head over to PowerShell!

First, store your token in an object, I will use $token.

Then we need to form the header as a bearer token:

$k8sheader = @{authorization="Bearer $($token)"}

This is the format needed to authenticate with that token.

Now you are ready!

To pull the storage classes for instance run:

Invoke-RestMethod -Method GET -Uri https://10.21.202.237:6443/apis/storage.k8s.io/v1/storageclasses -Headers $k8sheader -SkipCertificateCheck

You will need skip certificate check for now–I didn’t configure the certificate checking yet.

If we store the response in an object we can more easily dig in:

And find my default storage class.

Definitely a lot more for me to learn here, but it is a start!

Default FlashArray Connection With PowerShell

In the VMware Pure PowerShell module (PureStorage.FlashArray.VMware) there is a default array connection stored in a global variable called $Global:DefaultFlashArray and all connected FlashArrays in $Global:AllFlashArrays. The VMware/Pure PowerShell module automatically uses what is in the “default” variable.

The underlying “core” Pure Storage PowerShell module (PureStoragePowerShellSDK) does not yet take advantage of global connections. So for each cmdlet you run, you must pass in the “array” parameter. For example to get all of the volumes from an array:

Kind of annoying if you are interactively running commands and only have one array connection you care about (or one that you primarily care about).

Continue reading “Default FlashArray Connection With PowerShell”

Pure1 REST API Authentication Made Easy

I’ve been working with the Pure1 REST for about a year now and have really enjoyed what it brings. I’ve integrated it into a few things: PowerShell. vRO. vSphere Plugin. One of the “tricky” things about it though is the authentication. Instead of a username and password it requires the use of a RSA256 public/private key pair. This is inherently more secure, but of course requires a bit more know-how when it comes to pair generation.

I simplified a fair amount of it in PowerShell, but didn’t quite get to the finish line. The generation of the key pair could be done but it came in the form of a PFX–which basically combines the public key and private key into one file. Unfortunately, Pure1 requires the them to be separated as all it needs is the public key, not your private key. While this is “better” it does leave Windows users at a bit of a disadvantage–there is no built in mechanism to generate this without installing OpenSSL directly. The process could not be done entirely in PowerShell. Or so I thought…

Continue reading “Pure1 REST API Authentication Made Easy”

Mounting a VVol Datastore with PowerCLI

I’ve been making a lot of updates to my PowerShell module around VVols recently and this was the last “table stakes” cmdlet I wanted to add. There are certainly more to come, but now we definitely have the basics. In 1.2.2.1 release of the PowerShell module I added a cmdlet called Mount-PfaVvolDatastore.

As of today we support a single VVol datastore–though we are working on adding support for more than one.

Continue reading “Mounting a VVol Datastore with PowerCLI”

Assigning Read Access to Windows Private Key

I have written about authenticating with the Pure1 REST API, and my PowerShell module in the past:

https://www.codyhosterman.com/2019/01/using-the-pure1-rest-api-part-i-powershell/

NOTE: This workaround is not really needed anymore with the default behavior of the module. See this post: https://www.codyhosterman.com/2019/12/pure1-rest-api-authentication-made-easy/

One of the issues is that if you followed my default instructions, you would need to run the PowerShell window as an admin to be able to create the connection. The answer–now that I think about it is fairly obvious: non-admin users (or admins not running in admin mode) don’t have security rights to it. Duh!

Continue reading “Assigning Read Access to Windows Private Key”

Revamped PowerShell Module for Pure and VMware

About 6 months ago, my esteemed colleague Barkz blogged about our path forward with PowerShell. We have an official PowerShell SDK for managing the FlashArray–but it is limited to that: doing stuff to the FlashArray.

So to add value and make managing it within context of the layers you actually manage your infrastructure from (VMware, Microsoft, etc.) we created some value-add PowerShell modules to make it easier. Barkz talks about them here:

Continue reading “Revamped PowerShell Module for Pure and VMware”

Using the Pure1 PowerShell Module

Recently I wrote a blog post on how to authenticate and connect to Pure1 via PowerShell. You can find that here:

I have made authentication MUCH easier:

https://www.codyhosterman.com/2019/12/pure1-rest-api-authentication-made-easy/

But it is fairly involved, so I made it easier for you (and me) by writing a PowerShell module and posted in on the PowerShell Gallery.

https://www.powershellgallery.com/packages/Cody.PureStorage.Pure1/

Continue reading “Using the Pure1 PowerShell Module”

Using the Pure1 REST API Part I: PowerShell

In my last post, I spoke about the ins and outs of using the Pure1 REST API–but it was a fairly manual process. Which of course is not how you really want to use a REST API. So the first part of this series will be using it with one of my favorite tools: PowerShell!

I will separate this into five parts:

  1. Creating your certificate
  2. Adding your public key into Pure1
  3. Creating your JWT
  4. Authenticating with Pure1
  5. Making REST calls after authentication

UPDATE!!!! I made this much easier, you can use my module to connect to Pure1 which is on the PowerShell gallery.

You can find more information on it here:

https://www.codyhosterman.com/scripts-and-tools/pure1-rest-api/pure1-powershell-module/h

Continue reading “Using the Pure1 REST API Part I: PowerShell”