I’ve written about generating the JSON Web Token for Pure1 REST API authentication before. Mostly around PowerShell. Though of course many may not want to use PowerShell and prefer to opt for something like Python.
So here is the process.
We have a script posted on the support site here. But that actually doesn’t return the JWT, it creates a session. So it takes the next step after the JWT. But if you just want to generate the JWT so something else can authenticate it won’t do the trick. So I made some modifications and threw it on GitHub as a gist. You can get it here:
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…
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:
Creating your certificate
Adding your public key into Pure1
Creating your JWT
Authenticating with Pure1
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.
Hello there! The FlashArray and FlashBlade products from Pure have always had a REST API service built in–this REST service allows you to manage, provision, and pull raw statistics from the array.
But there are two pieces missing:
You need to iterate through each array if you want to intelligently place a volume on it (or find a volume or whatever)
They only offer raw statistics–you need to do some crunching possibly to get what you want. Create projections and forecast, find how busy an array is, etc.
Luckily this is what Pure1 does for you. Every customer has access to our Pure1 web tool. This is something we host, all of your dial-home information gets fed into it. We use that information to figure out how “busy” an array is, when it will fill up from a capacity or performance perspective and much more. We now offer a REST API for Pure1 as well, so you can do some one-stop shopping for the information you need, that the arrays cannot natively provide.
Awhile back I wrote about performing an operation introduced in Purity 4.6 called protection group copy, which I really referred to as protection group recovery, which I think is maybe a more apt title.
Anyways, this feature is available in our REST API and our CLI (not yet in our GUI in a direct format) but is not yet built into our PowerShell SDK. I have seen more than one request for information on how to do this, and it certainly can be done without our official SDK and this is through the good ol’ Invoke-RestMethod cmdlet built into PowerShell. I’ve spoken about using this many times, here and here.
Let’s walk through it specifically with protection group restore.
I wrote about some security changes in the FlashArray operating environment (called Purity) version 4.7 a month or so back. This was concerning the deprecation of SSL and TLS version 1.0, forcing all (management) connections to the FlashArray to use TLS 1.1 or 1.2 (read this here).
Our PowerShell SDK was enhanced so it would use the appropriate security connection type so users of that do not need to worry as long as they upgrade our SDK. But what about the few remaining functions that people might use that the PowerShell SDK doesn’t cover? As there are a few REST calls that are not built into the SDK (yet). Continue reading “Force the Invoke-RestMethod PowerShell cmdlet to use TLS 1.2”
I have quite a few PowerShell scripts these days and I run a bunch of them quite often. All of my scripts log information to a file so I can see what happened but I decided I wanted to log them into something that could help me analyze or quickly review the data. Something better than looking at a bunch of text files. One of my favorite products, VMware Log Insight was the first thing I thought of. The ingestion REST API makes the most sense. Took a little time to figure out the best way to do it, but it’s working great now. To the details!
Continuing my recent work on learning vRealize Orchestrator and ran into some funkiness with the “Invoke REST host” workflow, that I wanted to write down so I don’t forget how I fixed/worked around it (which I suppose is the impetus for basically every post I do). Anyways, I am working on a REST-based package for the FlashArray and I was using that workflow and had some trouble. Basically, any REST call I made through it to a REST host seemed to fail.
UPDATE: This is a older post, but after working with vRO for longer and learning a lot more about it I decided I needed to re-write this post. Too much of it was not the best way to do things.