Upgrading Policy Workbench in Azure

Steps to upgrade Policy Workbench on PPC in Azure Kubernetes Service (AKS) using OpenTofu and Helm.

Before you begin

Back up the existing Policy Workbench data.
For more information, refer to Backing up the Policy Workbench for Azure.
Before upgrading, ensure the existing managed identity, federated identity credential, and Key Vault role assignment are tracked in OpenTofu state.
- If any of these resources are untracked, import them with tofu import before running tofu apply. This prevents recreation conflicts.

Update to Configure credentials for the Policy Workbench

Perform the following steps to configure the credentials to access the Policy Workbench from the OCI registry.

Run the following command to create the configuration directory.
```
mkdir -p ~/.config/containers
```
Obtain the username and access token from the My.Protegrity portal. For more information about obtaining the credentials from the My.Protegrity portal, refer to the section Configuring Authentication for Protegrity AI Team Edition.
Generate base64 encoded string with padding for username:accesstoken obtained from the My.Protegrity portal.
Ensure that you specify the username and access token within single quotes when generating the base64 encoded value. For example, 'username:accesstoken'.
Note: For the Protegrity Container Registry, set <Container_Registry_Path> to registry.protegrity.com:9443. For a local registry, set it to the local registry endpoint.

Create a file named ~/.config/containers/auth.json with the following content.

{
    "auths": {
        "<Container_Registry_Path>": {
            "auth": "<base64 generated string from step-3>"
        }
    }
}

Upgrade the Policy Workbench deployment

To upgrade the Policy Workbench, refer to the appropriate section using the following links:

Root module was not available during installation

If no root module was available during installation, use a standalone root module for the upgrade. Start with the main.tf configuration using the following steps:

Navigate to the deployment directory.
Copy the main.tf contents from step 2 of Installing Policy Workbench when root module is not available.
Note: The new main.tf includes a kubernetes provider and additional module arguments, including oci_host, fips, arch, and instance_types, that were not present in earlier versions.
Replace the contents of the existing main.tf with the copied content.

In main.tf, set the following parameter values:

Parameter	Description	Value
`<version>`	Tag version of the Policy Workbench, as listed in the Policy Workbench README.	1.13.1
`<cluster_name>`	The name of the PPC cluster specified during deployment.	The value used for the cluster name when deploying PPC.
`resource_group_name`	The name of the resource group containing the AKS cluster.	The resource group used when deploying PPC.
`azure_keystore.type`	Type of keystore used.	Specify one of the following values: `key_vault` - Use Standard or Premium Azure Key Vault. Protegrity supports 3072-bit RSA software-backed Master Key type. The Master Key uses the RSA-OAEP-256 algorithm to encrypt the Data Encryption Key (DEK). `managed_hsm` - Use Azure Key Vault Managed HSM. Protegrity supports 256-bit AES oct-HSM HSM-backed Master Key type. The Master Key uses the AES-256-CBC algorithm to encrypt the Data Encryption Key (DEK). For more information about the Azure Key Vault, refer to About Azure Key Vault in the Azure documentation. For more information about the Azure Key Vault Managed HSM, refer to What is Azure Key Vault Managed HSM? in the Azure documentation. Note: Protegrity supports only software-protected keys for the Premium Key Vault. Protegrity does not support HSM-protected keys for the Premium Vault. For more information about software-protected and HSM-protected keys, refer to the Azure documentation. Important: You cannot migrate among the Standard Key Vault, Premium Key Vault, and Managed HSM.
`azure_keystore.name`	The name of the existing Standard or Premium Key Vault or Managed HSM.	Specify one of the following values: `var.key_vault_name` - Specify this variable if a Standard or Premium Key Vault is used. Set the value of this variable when running the `tofu apply` command in the Apply the Configuration section. The name of the existing Managed HSM.
`azure_keystore.resource_group_name`	Resource group of the Standard or Premium Key Vault or Managed HSM.	Specify one of the following values: `var.key_vault_resource_group_name` - Specify this value only if a Standard or Premium Key Vault is used. Set the value of this variable when running the `tofu apply` command in the Apply the Configuration section. Name of the resource group for the existing Managed HSM. Specify this parameter only if the name of the resource group for the Managed HSM differs from the value of the `resource_group_name` variable.
`fips`	Use a secure VM image for Karpenter nodes.	The default value is `true`. Set the value to `false` for standard nodes.
`arch`	CPU architecture for Karpenter nodes.	Uses the CPU architecture from installation.
`instance_types`	Azure VM sizes for Karpenter nodes.	Uses the VM sizes from installation.
`key_vault_name`	Name of the Azure Key Vault used to store the keystore.	The Key Vault name specified during deployment.
`key_vault_resource_group_name`	Resource group containing the Key Vault, if different from `resource_group_name`.	Defaults to `""`, which uses `resource_group_name`.

For more information about cluster_name, refer to Deploying PPC.

Ensure that the credentials to install the Policy Workbench from the Protegrity Container Registry have been configured.
For more information about configuring the credentials, refer to Configuring credentials for the Policy Workbench.

Root module was available during installation

If a root module was available during installation, follow these steps to update its policy_workbench module block and ensure that the required provider and Kubernetes cluster configuration are present in the root module:

Navigate to the root module directory.
Locate the policy_workbench module block in the .tf files.

Update the module block with the following:

Note: The oci_host, fips, arch, and instance_types arguments are new in this version. If the existing module block does not include them, add them along with the updated source value.

module "policy_workbench" {
   source = "oci://<Container_Registry_Path>/policy-workbench/opentofu/modules/policy-workbench/azure?tag=<version>"

   cluster_name        = var.cluster_name
   oci_host            = "<Container_Registry_Path>"
   resource_group_name = var.resource_group_name

   azure_keystore = {
     type                = "key_vault"
     name                = var.key_vault_name
     resource_group_name = var.key_vault_resource_group_name
  }

  fips           = var.fips
  arch           = var.arch
  instance_types = var.instance_types
}

Note: For the Protegrity Container Registry, set <Container_Registry_Path> to registry.protegrity.com:9443. For a local registry, set it to the local registry endpoint.

In the policy_workbench module block, set the parameter values as specified in the parameter table.

If the root module does not include the following provider versions, add them to the terraform {} block:

hashicorp/azurerm version ~> 4.20
hashicorp/kubernetes version ~> 2.35

required_providers {
  azurerm = {
    source  = "registry.opentofu.org/hashicorp/azurerm"
    version = "~> 4.20"
  }
  kubernetes = {
    source  = "registry.opentofu.org/hashicorp/kubernetes"
    version = "~> 2.35"
  }
}

Configure the kubernetes provider to connect to the target AKS cluster by adding the following to the root module:

data "azurerm_kubernetes_cluster" "this" {
 name                = var.cluster_name
 resource_group_name = var.resource_group_name
}

provider "kubernetes" {
  host                   = data.azurerm_kubernetes_cluster.this.kube_config[0].host
  client_certificate     = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_certificate)
  client_key             = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_key)
  cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].cluster_ca_certificate)
}

Ensure that the credentials to update the Policy Workbench from the Protegrity Container Registry have been configured.
For more information about configuring the credentials, refer to Configuring credentials for the Policy Workbench.

Apply the configuration

Navigate to the directory containing the configured main.tf file. Run the following steps from that directory to initialize the OpenTofu providers and apply the configuration:

Run the following command to initialize the OpenTofu providers:
```
tofu init -upgrade
```

Run the following commands to preview and apply the OpenTofu changes:

tofu plan \
  -var="cluster_name=<cluster-name>" \
  -var="resource_group_name=<resource_group_name>" \
  -var="key_vault_name=<key_vault_name>"

tofu apply \
  -var="cluster_name=<cluster-name>" \
  -var="resource_group_name=<resource_group_name>" \
  -var="key_vault_name=<key_vault_name>"

OpenTofu displays the plan and prompts for confirmation before applying. Enter yes to proceed, or add the -auto-approve flag to the tofu apply command to skip the prompt.

Deploy the Upgrade with Helm

Run the following command to upgrade Policy Workbench:

helm upgrade --install policy-workbench \
  oci://<Container_Registry_Path>/policy-workbench/helm/policy-workbench \
  --version <version> \
  --namespace policy-workbench \
  --values policy-workbench-values.yaml

Note: For the Protegrity Container Registry, set <Container_Registry_Path> to registry.protegrity.com:9443. For a local registry, set it to the local registry endpoint. Set the value of <version> as specified in the parameter table.

The policy-workbench-values.yaml file is generated by the OpenTofu module in the working directory during the previous step. If the file is missing, re-run the tofu apply command from the Apply the Configuration step, with the same -var values, before proceeding.

If the upgrade succeeds, Helm displays the following output:

NOTES:
Protegrity policy-workbench 1.13.1 installed

The version number reflects the upgraded version.

Verify the upgrade

Confirm that the Helm release and pods are running correctly.

Run the following command to verify the Helm release status:

helm list -n policy-workbench

The output appears as follows:

NAME                NAMESPACE           REVISION    UPDATED                                     STATUS      CHART                       APP VERSION
policy-workbench    policy-workbench    4           2026-09-08 05:50:45.367488574 +0000 UTC     deployed    policy-workbench-1.13.0    1.13.1

The REVISION number increments with each upgrade.

Run the following command to verify the Policy Workbench pods are running:

kubectl get pods -n policy-workbench

The output appears as follows:

NAME                         READY   STATUS    RESTARTS   AGE
bootstrap-7dcff9dd5f-v6p8s   1/1     Running   0          16h
cert-84f768f744-6vzqd        1/1     Running   0          16h
devops-6dc846566-crglt       1/1     Running   0          16h
hubcontroller-0              1/1     Running   0          17h
hubcontroller-init-fcrww     1/1     Running   0          16h
kmgw-0                       1/1     Running   0          17h
kmgw-create-keystore-9c27h   1/1     Running   0          16h
mbs-d88d59965-lcwsh          1/1     Running   0          16h
repository-0                 1/1     Running   0          16h
rpproxy-5c8ddbff69-hncbx     1/1     Running   0          16h

All pods must show 1/1 under READY and Running under STATUS. Pod names and ages may differ across environments.

If the Helm release status is deployed and all pods meet these criteria, the Policy Workbench upgrade is complete.

Validate the Deployment

Confirm that the Policy Workbench API is accessible after the upgrade.

Ensure kubectl is configured to use the target AKS cluster:

az aks get-credentials --resource-group <resource_group_name> --name <cluster-name> --overwrite-existing

Run the following command to retrieve the gateway address:

export GW_HOST="$(kubectl get gateway pty-main -n api-gateway -o jsonpath='{.status.addresses[0].value}')"

Run the following command to obtain an authentication token for the workbench user:

export TOKEN=$(curl -k -s https://$GW_HOST/pty/v1/auth/login/token \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'loginname=workbench' \
  -d 'password=<workbench-password>' \
  -D - -o /dev/null 2>&1 | grep -i 'pty_access_jwt_token:' | sed 's/pty_access_jwt_token: //' | tr -d '\r')

Set <workbench-password> to the workbench user password specified during deployment. Confirm that $TOKEN is not empty before proceeding.

Run the following command to verify access to the Policy Workbench datastores API:

curl -k -v https://$GW_HOST/pty/v2/pim/datastores -H "Authorization: Bearer $TOKEN"

The response should list any existing datastores. If no datastores have been created, the response should be an empty array [].

Last modified : October 28, 2026

Feedback

Was this page helpful?