Harrison 
There was a project to package the CIS CAT Pro benchmark audit tool for Windows and Linux. The Windows-specific challenges I’ve experienced apply whenever you need to extract Java for Windows, or need to extract gzip or tar archives on Windows, without using 7zip. Since CIS CAT Pro requires Java, I wanted to create a zero-footprint Java installation that I could completely erase by deleting the folder. This makes automation easier to use in production systems, as it does not force a Java installation or conflict with existing versions of Java. (I find it ironic that CIS CAT requires Java, but it frequently flags the copy of Java it uses as problematic)
7zip has quite a few security vulnerabilities, so where I work, installing or using 7zip can result in several security warnings. So I needed a solution that didn’t use 7zip.
It’s a little frustrating that Java is only provided by Oracle as a gzipped tarball for Windows, but this approach is problematic for others that are only provided as gzipped tarballs for Windows. It works without any problems.
Applying infrastructure as code: principles of minimalism
The term Infrastructure as Code is thrown around a lot, but there is less specificity about how adopting this approach will impact your coding choices. Sometimes people only think of it in terms of a desired state configuration management platform like Chef, Puppet, or Ansible.I’ve heard others refer to it purely as setting things up Other than Actual end nodes – similar to what Terraform does.
When we think of infrastructure as code, it includes everything from imperative to declarative, OS-oriented or hypervisor-oriented. To me, the pure definition of Infrastructure as Code is that every last piece of configuration can be checked into source control, and the hardcore disciplines of traditional development are applied (e.g. structured code, lots of testing, etc.) It means that.
In other words, if the imperative code at the bottom of the stack (which is always the basis for declarative systems) remains the easy and dirty administrative coding of the past, it can become the Achilles heel of the rest of the stack. Sho.
If you’re lucky enough to live in a pure PaaS or FaaS (serverless) world, this required level probably doesn’t exist (but then you probably wouldn’t have gotten this far in this article either; ))
I’ve long felt that keeping the code to a minimum around the most practical implementation gives you more flexibility when engineering than you originally expected. This was a recurring theme. Recently, I found that very idea advocated in the book FIRE: How to Innovate Fast, Cheap, Disciplined, and Elegant. Choosing a basic implementation often reduces prerequisites and increases implementation scope. This aspect of coding is somewhat unique for developing automation aimed at a wide audience (at least those with well-written installation code), as business applications rely on bringing in all the dependencies. I do ;))
When working on automating operating system provisioning and software deployment, I frequently work with bootstrap automation, systems that do not have additional features or are in a build environment where additional features are not readily available. In addition, it is often necessary to migrate the OS from a fresh boot state in order to complete the software stack running on a single orchestration set. Addressing these constraints automatically reduces external dependencies on things that aren’t shipped. This is why I write code in PowerShell and Bash. The shipping versions of these languages are usually sufficient for everything you want to do. Reducing dependencies not only means you can get to the actual configuration work sooner, but it also means you don’t clutter your system with a bunch of installations that have nothing to do with the final software stack that runs on top of it. It means that. Additionally, the Windows world is constantly dealing with the fact that exe and msi-based installers often require special handling, such as rebooting. What a pain to find yourself in this situation when you just need a specific utility to automate the installation.
The first phase of the minimal approach is to ask, “Is there anything on my machine that can already perform this task?”
.NET (and therefore PowerShell) has a class for standard .zip extraction (system.io.compression.filesystem), which at first glance appears to contain an attempt to handle Linux archiving technology. But this is not perfect, it is not complete. Handles both gzip and tar.
In fact, using system.io.compression.filesystem is another practice of minimalism. This has the following advantages over using the Windows Explorer unzipping feature found in many code samples:
- Works on non-GUI OS variants such as Server Core, Containers, and Nano Server (does not work with Windows Explorer calls).
- Compatible versions are great and work with PowerShell 2-6 (Server 2008 R2-2019). *-Archive CMDLet is only available on later versions of Windows.
Other options investigated:
- Very recent versions of Windows come with Tar, but Microsoft-compiled versions of tar are not available for download on earlier versions of Windows.
- Binaries compiled by third parties (with the Windows tar option) are also not available.
- Most other third-party tars rely on heavy runtime libraries like Cygwin – a bit overkill to unzip a single file 🙁
Another IaC principle that I apply is that software and utilities that are only needed for installation or temporary purposes should not be fully installed and integrated if at all possible (even if they are removed later). This is “minimalism” a bit broader than what type of code or utilities are used to perform the installation. In this case, it affects both the installation automation and the whole idea of introducing his CIS CAT into the system. The reason for deploying CIS CAT on a system has nothing to do with what the software stack on that system is designed to do for the customer. Therefore, efforts must be made to minimize the impact on the target system. CIS CAT is a special concern because CIS CAT may be the only reason Java needs to be on a particular system. Therefore, CIS CAT must be isolated and easily removed. This level of minimalism means that the design, which allows CIS CAT and Java installations to be self-isolated and easily removed, applies to both Linux and Windows.
Below is a summary of the benefits of using tarballs instead of installer editions.
- By not installing Java completely, you are not changing the machine’s configuration (such as system paths) in a way that cannot always be reverted gracefully.
- By not installing Java completely, local applications that use Java will no longer have problems (by upgrading Java or removing older versions).
- You can choose the Java version based solely on compatibility with the app you are using (CIS-CAT in this case).
- For temporary purposes, cleanup is very easy.
- Can support easy clean-off installations of CIS CAT for Windows and Linux for CIS CAT 3 and 4 (four editions in total). CIS CAT has a “dissolvable bundle”, but it does not allow you to choose the Java version and is only compatible with Windows and CIS CAT v3.
option
I’d like to mention that I tried tartool.exe, but this depends on the assembly I ended up using, but unfortunately tartool asked me to install .NET 3.5/2.0. Not only do you not want to have this older version of .NET installed on your system, but many versions of Windows require this particular optional OS feature to be obtained from Microsoft, which frequently fails to deploy.
Since this is primarily for Amazon instances, Amazon’s Corretto Java was tried (it comes in Zip format). However, it was not compatible with at least some CIS CAT tests.
I finally settled on calling the assembly ICSharpCode.SharpZipLib.dll directly from PowerShell to unzip the Oracle edition.
The following code downloads SharpZipLib, extracts it, and uses it to extract Java. Look closely, because the line to get SharpZipLib contains a little but surprisingly useful secret. A .nupkg file is actually just a .zip file. This means that any .nupkg file found on nuget.org or Chocolatey.org can be downloaded, extracted, and minimized using its contents. In fact, the Universal OpenSSH installer I created can be used to install more than just chocolate, taking advantage of this very fact.
Another point of IaC minimalism – it turns out that SharpZipLib is available with the “Install-Package” command – but below I chose to download the .zip directly for the following reasons:
- We often need to automate out-of-the-box configurations of Windows, but before PowerShell 5, there was no package management.
- SharpZipLib also leaves no residue on your system. A simple delete will clean it up. This is not how package management works.
- When you use package management for the first time on a particular machine (which is very often used in deployment automation), all the underlying parts and pieces (package providers, package sources) are automatically configured and used. You need to use some commands and switches to make it work. This makes the system even more dirty and results in a configuration that is not easy to restore.
- With package management, the location of the extracted assembly can move, so you don’t have to explore to find it.
code
Invoke-WebRequest -uri ' -outfile "$PWD/SharpZipLib.1.1.0.nupkg"
Add-Type -assembly "system.io.compression.filesystem"
[io.compression.zipfile]::ExtractToDirectory("$PWD/SharpZipLib.1.1.0.nupkg","$PWD")
Write-host "Untaring Java..."
Add-Type -Path "$PWDlibnet45ICSharpCode.SharpZipLib.dll"
$gzippedtarball = [IO.File]::OpenRead("$PWDjre-8u212-windows-x64.tar.gz")
$inStream=New-Object -TypeName ICSharpCode.SharpZipLib.GZip.GZipInputStream $gzippedtarball
$tarIn = New-Object -TypeName ICSharpCode.SharpZipLib.Tar.TarInputStream $inStream
$archive = [ICSharpCode.SharpZipLib.Tar.TarArchive]::CreateInputTarArchive($tarIn)
$archive.ExtractContents($PWD)
$env:JRE_HOME="$PWDjre1.8.0_212"
$env:PATH="$env:JRE_HOMEbin;$env:PATH"
Darwin, why not try recreating the zip?
Given all this, you may be wondering, “Why not just unzip and recompress the Java archive?” The reasons I don’t do that, based on harsh experience, are:
- The more manual steps a re-release requires, the more likely it is that adoption of the new version will be postponed. And in this case, it’s Java.
- The more manual steps a re-release involves, the more likely it is that a step will be missed.
- Every time a file bundle is extracted, there’s always a risk (yes, I’ve seen it many times) that someone will try to find out what’s in the new bundle.
- When working with installers, I always prefer to use vendor files directly. This method uses known preparations and may also include vendor checksums that can be checked.
- If you are sure that your solution can handle the original file, it might even automatically download the file (which may not always be the best choice for other reasons).
An overview of the infrastructure as code principles employed in this solution
- Keep automation dependencies to a minimum.
- When installing something for administration, management, or troubleshooting purposes, avoid using a package manager so that these items and their dependencies do not change the mix of software used in the main software stack. please.
- Use features outside of your chosen language to expand your “supported” scope. For example, this solution used “system.io.compression.filesystem” for the broadest possible normal decompression support (non-GUI windows and PowerShell 2-6). Another example is preferring schtasks.exe over PowerShell ScheduledTask CMDLet.
- Whenever possible, use isolated file-only (portable) installations to minimize system clutter. This makes cleanup easier.
- If you need support for PowerShell versions that don’t have package management built in, download the .nupkg and process it manually.
- Downloading and extracting the .nupkg prevents the scripts inside from running and compromising your configuration.
Extract GzippedTarballWithout7Zip.ps1
