Auto-Deployment Of Windows Container Defenders to GKE Window nodes

[JOmoniyi]

By Omoniyi Jabaru, Senior Customer Success Engineer

Overview

This document presents a step-by-step guide for automating the deployment of Prisma Cloud Windows container defender to Google Kubernetes Engine Windows nodes. You will set up a Kubernetes cluster with a Windows node-pool and leverage the Google Cloud startup scripts on Windows VMs to install the Prisma Cloud container defenders. We will discuss installation of Prisma Cloud defender on Windows Google Kubernetes Engine clusters.

Purpose

The DaemonSet version of the Prisma Cloud defender is not supported on such clusters; we will deploy an individual defender on each node in said Windows GKE cluster. To avoid manual installation and make this process scalable, we will make use of a startup script functionality offered by Google Cloud. This way any newly added Windows node to the GKE cluster will automatically get Prisma Cloud Defender installed after booting up.

Definition - Google Cloud Startup Scripts

A startup script is a file that performs tasks during the startup process of a virtual machine (VM) instance. Startup scripts can apply to all VMs in a project or to a single VM. Startup scripts specified by VM-level metadata override startup scripts specified by project-level metadata; startup scripts only run when a network is available. 

This document describes how to use startup scripts on Windows Server VM instances. For information about how to add a project-level startup script, see gcloud compute project-info add-metadata. Windows startup scripts must be Command shell (.cmd), PowerShell (.ps1), or batch file scripts (.bat), and must have the appropriate file extension.

If you specify a startup script by using one of the procedures in this document, Compute Engine does the following:

• Copies the startup script to the VM
• Task Scheduler runs the startup script as the LocalSystem account when the VM boots

Objective

The primary goal of using a startup script in the context of virtual machine (VM) instances, whether they are Windows Server VMs or Linux VMs, is to automate the initialization and configuration process during the startup phase. Startup scripts are particularly useful for performing tasks that need to be executed consistently across multiple VM instances or whenever a VM instance is launched or rebooted.

Here are some key goals and benefits of using startup scripts:

• Automating Setup Tasks: Startup scripts automate the execution of setup tasks such as installing software packages, configuring system settings, initializing services, and downloading dependencies. This reduces the need for manual intervention and ensures consistent configuration across VM instances.

• Enhancing Security: Startup scripts can include security configurations and hardening measures to strengthen the security posture of VM instances. This may include applying security patches, setting up firewall rules, enabling encryption, and configuring access controls.

• Improving Efficiency: Startup scripts save time and effort by automating repetitive tasks that would otherwise need to be performed manually. This allows administrators to focus on higher-level tasks and strategic initiatives rather than routine maintenance.

• Ensuring Consistency: By defining startup scripts, administrators can enforce standardized configurations and procedures across VM instances within their environment. This consistency helps in maintaining a predictable and stable infrastructure.

In summary, startup scripts enhance operational efficiency, ensure consistency, strengthen security, support scalability, and enable agile infrastructure deployment practices.

Figure 1: Startup Script workflow_palo-alto-networks

Environment

• Prisma Cloud Compute Enterprise Edition
• GKE Cluster
• Windows Node Pool
  
  

Prerequisites

This document assumes that you are using PowerShell to execute the scripts required to generate the startup script to install the Windows Container Defender.

Part 1: Generate Startup Script

Step 1: Defender Installation Script

Create a script.ps1 file with the following content:

$Url = "https://us-east1.cloud.twistlock.com/us-1-123456789"

$Body = @{

    username = 'ACCESS_KEY'

    password = 'SECRET_KEY'

}

$token = (Invoke-RestMethod -Method 'Post' -Uri $Url/api/v1/authenticate -Body ($Body | ConvertTo-Json) -ContentType 'application/json').token

$parameters = @{ 

    Uri = "$Url/api/v1/scripts/defender.ps1"

    Method = "Post"

    Headers = @{

        "authorization" = "Bearer $token" 

    } 

    OutFile = "defender.ps1" 

}

Invoke-WebRequest @parameters

.\defender.ps1 -type containerdWindows -consoleCN us-east1.cloud.twistlock.com -install

Figure 2: script.ps1 script content_palo-alto-networks

Here's a breakdown of what the script does:

• Authentication: It sends a POST request to the Twistlock API endpoint /api/v1/authenticate with the provided username and password. The response contains an authentication token ($token), which is used in subsequent requests for authorization.

• Download Defender Script: It sends a POST request to the Twistlock API endpoint /api/v1/scripts/defender.ps1 to fetch the PowerShell script for Twistlock Defender. The script is saved locally as defender.ps1.

• Execution of Defender Script: It executes the downloaded defender.ps1 script with specific parameters, including the type of defender and the Twistlock console's name. The type of defender can be containerdWindows or dockerWindows. Since the Windows nodes in GKE cluster run on containerd by default, then the defender type must be containerdWindows. The twistlock console name is the IP or DNS that is being used for the defenders to connect to the console. In this scenario, that console name is us-east1.cloud.twistlock.com, which is the console name for Prisma cloud tenant APP and APP2.

Before running this script, ensure that you have the necessary permissions and credentials to access the Twistlock console and execute the Defender script. Also, ensure that you replace 'ACCESS_KEY' and 'SECRET_KEY' with your actual Twistlock credentials, and replace the $Url value and twistlock console name for the ones that belong to your Prisma Cloud Compute console.

Step 2: PowerShell to CMD Script

Create a ps1_to_cmd.ps1 file with the following content:

$s = Get-Content script.ps1 | Out-String

$j = [PSCustomObject]@{

  "Script" =  [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($s))

} | ConvertTo-Json -Compress

$oneline = "[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String(('" + $j + "' | ConvertFrom-Json).Script)) | iex"

$c = [convert]::ToBase64String([System.Text.encoding]::Unicode.GetBytes($oneline))

("Powershell -NoLogo -NonInteractive -NoProfile -ExecutionPolicy Bypass -Encoded " + $c) | Out-File -Encoding Default script.cmd

Figure 3: ps1_to_cmd.ps1 script content_palo-alto-networks

This PowerShell script converts another PowerShell script (script.ps1) into a one-liner encoded command that can be executed as a command-line script (script.cmd). The script.cmd file is encoded and contains the encoded PowerShell command.

The main reason why the PowerShell script transformed to a CMD script is because GKE Windows nodes already have in place a PowerShell startup script, so in this scenario we need to put in place a CMD startup script which by default will be executed after the PowerShell startup script. 

Refer to Google Cloud documentation for more information.

Part 2: Inject Startup Script

GKE Creation Method - this method applies when you create a GKE Cluster

Step 1: Navigate to Kubernetes engine 

• Sign in to Google Cloud Console
• Navigate to Kubernetes Engine: From the Google Cloud Console dashboard, navigate to "Kubernetes Engine" from the left-hand side menu under the "Compute" section.

Step 2: Create GKE Cluster 

• Click on the "Create" button to start creating a new GKE cluster.
• Click on “Configure” for Standard cluster creation.
• Enter a name for your cluster in the "Cluster name" field.
• Choose a location for your cluster under the "Location type" dropdown menu. Select a zone where Windows Server containers are supported.
• Configure the desired node pools by clicking on "Add node pool". In the node pool configuration: Choose the desired machine type.
• Specify the number of nodes.
• On the nodes tab, select the appropriate operating system by choosing the Windows version under the "Operating system" dropdown menu.
• On the metadata tab, navigate to the GCE instance metadata section.
• Click on the “Add Metadata” button.
• In the Key 2, insert the key windows-startup-script-cmd
• In the value 2, insert the one-liner encoded command contained in the file script.cmd

Figure 4: inject startup script while creating a GKE Cluster_palo-alto-networks

• Click on “Create”

Part 2a: Add Nodepool Method.

This method applies when you add a Windows Nodepool to an existing GKE Cluster

Step 1: Navigate to Kubernetes engine 

• Sign in to Google Cloud Console
• Navigate to Kubernetes Engine: From the Google Cloud Console dashboard, navigate to "Kubernetes Engine" from the left-hand side menu under the "Compute" section.

Step 2: Add Nodepool

• Click on the cluster you want to add a Windows nodepool to.
• Click on the “Add Nodepool” button.
• Specify the number of nodes.
• On the nodes tab, select the appropriate operating system by choosing the Windows version under the "Operating system" dropdown menu.
• On the metadata tab, navigate to the GCE instance metadata section.
• Click on the “Add Metadata” button.
• In the Key 2, insert the key windows-startup-script-cmd
• In the value 2, insert the one-liner encoded command contained in the file script.cmd

Figure 5: inject startup script while adding a nodepool_palo-alto-networks

• Click on “Create”

Part 2b: Update Nodepool Method

This method applies when you want to update an existing Windows nodepool and install the Windows Container Defender on existing nodes and nodes that will be created.

Step 1: Navigate to Kubernetes engine 

• Sign in to Google Cloud Console
• Navigate to Kubernetes Engine: From the Google Cloud Console dashboard, navigate to "Kubernetes Engine" from the left-hand side menu under the "Compute" section.

Step 2: Update Nodepool

• Click on the cluster you want to update the existing Windows nodepool.
• Click on “Nodes”
• Click on the Windows Nodepool you want to update.
• On the Instance Groups section, click on one instance group.
• Click on the “Update VMs” button.
• Navigate to the “All instances Configuration” section.
• Click on “Manage Metadata”.
• Click on “Add Metadata”.
• In the Key 2, insert the key windows-startup-script-cmd
• In the value 2, insert the one-liner encoded command contained in the file script.cmd

Figure 6: inject startup script on an existing nodepool_palo-alto-networks

• Click on “Save”
• Click on “Update VMS”

Update all Instance groups in the nodepool by adding the windows-startup-script-cmd metadata value.

Step 3: Restart VMs

This step is taken to install the Windows Container Defender on existing nodes. The process is as follows:

• Inside an Instance Group of the Windows Nodepool, click on “Restart/Replace VMS”
• The Operation should be on “Restart” and the Maximum unavailable instances should be 1.

Figure 7: restart VMs of existing instance group_palo-alto-networks

• Click on “Restart VMS”

Do this process for all the instance groups in the nodepool.

Part 3: Verify Defenders

Step 1: Navigate to Prisma Cloud Defenders Section

• Open Prisma Cloud Console.
• Go to Compute > Manage > Defenders > Defenders: Deployed

Figure 8: Defenders connection verification_palo-alto-networks

You should see Windows Container Defenders in the connected status.

Additional Information 

You can also deploy the Windows container defender to protect your containers running on Azure Kubernetes Service (AKS) Windows nodes with containerd runtime. By installing the Defender you will be able to view the running containers and images on the Radar and leverage Prisma Cloud Runtime Defense capabilities on the running containers.

Conclusion

It’s possible to install a Windows Container Defender on GKE Windows nodes and automate this installation process by using the windows-startup-script-cmd metadata key with a one-liner encoded command-line script as its value. This Defender can also be installed on brand new Windows nodes and existing ones. 

References: 

[1] ps1_to_cmd.ps1

[2] About Startup Scripts

[3] Use startup scripts on Windows VMs

[4] Deploy Windows Defender

[5] Google Cloud Metadata

About the Author

Omoniyi Jabaru is a senior customer success engineer specializing in Prisma Cloud, Next-Generation Firewall, AWS, Azure, GCP, containers and Kubernetes. He uses simple approaches to break down complex problems into solutions for global enterprise customers and leverage their multi-industry knowledge to inspire success.