PowerShell Quality of Life Improvements – PS Repository

In the last post, we were able to create a Release Pipeline that takes checked and signed Powershell code and deploys it to target servers. In some situations, it may not be desirable or viable to have every server configured as a deployment target. Or there may be a need to have an additional amount of control of the modules that a server gets. To deal with these issues, we can look at setting up a PowerShell Respoistory as an intermediatory step.

Setting Up The Respository

The Respository can be as simple as a file share on a server. At the higher end of complexity, it can be a website running NuGet Gallery. For this case, I’ve gone simple. By using a file share, we negate the need for setting up API keys and the like that a NuGet Gallery would need.

Once the PowerShell Respoistory is created, it needs to be registered on the relevant targets. This is achieved using the Register-PSRepository cmdlet, as shown below:

Register-PSRepository -Name psqol -SourceLocation "\\svr14\psrepo\" -PublishLocation "\\svr14\psrepo\" -InstallationPolicy Trusted

If the InstallationPolicy value is set to “Untrusted”, then there will be a user prompt when attempting to install modules from the Repository.

Read more

PowerShell Quality of Life Improvements – Release

Releasing a build is typically the final step in the process of developing code. For PowerShell, this takes the form of getting our signed scripts and modules onto target servers to be available for use. This can be easily achieved in Azure DevOps.

Deployment Groups/Targets

The deployment tasks will run on the targets will recieve the scripts. Before that, a Deployment Group needs to be created. This is done by navigating to Pipelines > Deplyment Groups and clicking “Add new deployment group”. The group needs to be given a name.

Read more

PowerShell Quality of Life Improvements – Automatic Versioning

Once we start doing processes like putting PowerShell code into git repositories, signing it and effectively creating new versions of it, it becomes useful to be able to automatically manage the versioning of our scripts and modules. The version number acts as an easy visual indicator of whether the script is the latest or not.

Introducing Token Replacement

Since the version number will change with each “build”, we will want to put in some sort of place holder value – a token. In my sample module, I change the version value to reference this token:

# Version number of this module.
ModuleVersion = '#{fullVersion}#'

Read more

PowerShell Quality of Life Improvements – Code Signing

PowerShell uses Execution Policies to control whether a script can be run or not. Some of these policies rely on scripts being digitally signed by a trusted publisher. By signing your scripts, you can look at implementing a more restrictive Execution Policy that increases security. The first step in this process is getting a certificate.

Code Signing Certificate

To sign your scripts, you need a special type of certificate, one for code signing. If your scripts will be for internal use only and your organisation has an internal PKI, then using a code signing certificate from that PKI will be enough. If you are writing scripts or modules for consumption by a broader audience, then you’ll need a code signing certificate from a 3rd party Certificate Authority.

Read more

VMSA-2022-0007 – VMware Tools vulnerability

VMware have published a new security advisory relating to VMware Tools for Windows. It affects v10 and 11 of the Tools. The vulnerability allows a user with local admin rights in the guest OS to acquire system privileges.

The version with the fix for this vulnerability is 12.0.0. While this is a major version jump, from the release notes there doesn’t appear to be any major breaking changes. It still supports Windows as far back as 7 SP1/2008 R2 SP1.

PowerShell Quality of Life Improvements – Code Testing

PowerShell has been around for 15 years now. One of the changes that has happened in the IT industry in that time is the rise of DevOps, and the associated tools and technology with it. If we consider the process of creating and consuming PowerShell scripts, it can be applied to the major stages of software development – test, build, release. By using the methods associated with this, we can look at improving the quality of PowerShell code we deliver.

Why Do Code Testing?

Code testing can cover a broad spectrum of activities. At the most basic end is syntax checking or a “linter” to perform static code checking. At the complex end, there’s things like unit tests. For the sake of this example, I’ll be using a “linter”, the PS Script Analyzer. By using such a tool on our code, we can establish whether it meets minimum quality requirements. PS Script Analyzer comes with an array of built-in rules and can be extended with your own rules.

Creating The Code Test Pipeline

The first step is to create a pipeline that will perform the code testing activities. In my case, I’m using Azure DevOps, but a similar approach can be used with Github. The pipeline itself is relatively simple, with two tasks. One will install the PS Script Analyzer module, as it’s not installed by default on Azure DevOps agents. The second task will execute the analysis process. The pipeline code is shown below:

Read more

vRealize Automation 8.6.2

Normally I wouldn’t write about a minor release but in this case I think it’s worth mentioning. On 18th January, VMware released version 8.6.2 of vRealize Automation. The big item in this release is that log4j has been updated to resolve some of the vulnerabilities that have been discovered.

Log4J Updated to 2.17

Starting in December 2021, a number of vulernerabilities were discovered in the Log4J logging utility. Log4j is used in a lot of other products to allow easy logging functionality. The first vulnerability, dubbed “Log4Shell”, was given a CVSS score of 10. The CVE ID assigned was CVE-2021-44228. As per the Release Notes, this is one of the CVEs that 8.6.2 resolves.

The second vulnerability mentioned in the Release Notes is CVE-2021-45046. Like the first vulnerability, it can also be exploited remotely and was considered quite severe. There have been two further vulnerabilities that have been discovered, however according to VMware, they can’t be exploited on their products.

Resouce Center

One key interface change is the Deployments tab is now called Resources. It seems the intent here is to create a consolidated view of all resources and integrate day 2 actions. There’s also the ability to quickly create a simple VM in this area, without the need for a Cloud Template. How useful that ends up being is up for debate.

Final Thoughts

As with a lot of the updates over 2021, this one adds a few nice improvements. The official fix for Log4j is reason enough to get on this version.

VMSA-2021-0020 – 19 vulnerabilities on vCenter

VMware published a new security advisory overnight (VMSA-2021-0020) and it’s a big one. In total, it lists 19 vulnerabilities affecting multiple versions of vCenter. The most serious of the vulnerabilities is the first one – CVE-2021-22005. This vulnerability allows an attacker to upload files to vCenter. This vulnerability could then be used as an avenue to execute code. It’s been giving a CVSS score of 9.8

The second most worrying item on the list (CVE-2021-21991) allows an attacker to escalate their priveleges to Administrator level in the vSphere web interface. This vulnerability has been scored at 8.8.

The resolution for all these vulnerabilities is to update vCenter to the appropriate version. The advistory lists these, and I’ve produced a condensed version below.

Product/VersionUpdate ToNotes
vCenter 7.07.0 U2dThe majority of issues are fixed by going to U2c. U2d resolves CVE-2021-22011 and CVE-2021-22018
vCenter 6.76.7 U3oThis version will resolve all the associated issues with 6.7
vCenter 6.56.5 U3q This version will resolve all the associated issues with 6.5

Given the nature of some of these vulnerabilities, this would be one to get onto ASAP.

vRealize Automation 8.5 Released

A few days ago, VMware released an update for vRealize Automation (vRA). The list of improvements seems relatively minor this time, as detailed in the Release Notes. It seems the biggest change was mentioned in the blog announcement for this release, where vRA is moving to monthly releases. Since these updates are feature focused, that potentially means a more frequent update cycle for administrators. Hopefully this means the update process will become smoother going forward. From personal experience, it’s been a bit hit and miss.

Close Bitnami banner
Bitnami