Installing Policy Workbench

Policy Workbench is installed on an existing, supported PPC installation running on AKS.Prepare the Azure and Kubernetes resources needs using one of two methods:

• Module-managed Workbench resources: Use the provided policy-workbench OpenTofu module to prepare the resources on the existing cluster. The OpenTofu installation procedure depends on whether a root module is available.

  For more information about OpenTofu modules and the root module, refer to Modules in the OpenTofu documentation.

• Self-managed Workbench resources: Prepare and manage those resources through the existing infrastructure process.

  For more information on deploying PPC onto an existing AKS cluster, refer to In-cluster deployment.

Both methods install Policy Workbench with Helm. The following sections describe the resource preparation and installation steps for each method.

Installing Policy Workbench

To install Policy Workbench, select an installation path:

• Module-managed Workbench resources
• Self-managed Workbench resources

Module-managed Workbench resources

Use this path when the policy-workbench OpenTofu module should prepare the Azure and Kubernetes resources required by Policy Workbench on the existing AKS/PPC cluster. After OpenTofu completes, install the Helm chart using the generated Helm values file, policy-workbench-values.yaml.

Module prerequisites

• Ensure that the PPC installed and accessible, before installing Policy Workbench on PPC. For more information about deploying the PPC cluster, refer to Automated script-based installation or Manual component-based installation.
• The policy-workbench OpenTofu module creates a federated identity credential bound to the AKS OIDC issuer URL and the workbench-kms ServiceAccount.

Configuring Credentials for the Policy Workbench

Configure credentials for the approved Protegrity Container Registry using the following instructions:

1. Run the following command to create the configuration directory.

   mkdir -p ~/.config/containers
   

2. 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.

3. 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.

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

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

Follow the instructions for the scenario that matches whether a root module is available. Refer to the appropriate section using the following links:

• Root module is not available.
• Root module is available.

Installing Policy Workbench when root module is not available

Install the Policy Workbench using the following steps:

1. Run the following command to create the deployment directory:

   # must install from an empty directory
   mkdir policy-workbench && cd policy-workbench
   

2. Create a root module with a single main.tf file:

   terraform {
     required_version = "~> 1.10"
   
     required_providers {
       azurerm = {
         source  = "registry.opentofu.org/hashicorp/azurerm"
         version = "~> 5.7"
       }
       kubernetes = {
         source  = "registry.opentofu.org/hashicorp/kubernetes"
         version = "~> 2.35"
       }
     }
   }
   
   provider "azurerm" {
     features {}
     resource_provider_registrations = "none"
   }
   
   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)
   }
   
   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
     # Defaults:
     # fips = true
     # arch = "arm64"
     #
     # Default ARM64 node type:
     # instance_types = ["Standard_D8ps_v5"]
     #
     # AMD64 deployment:
     # arch = "amd64"
     # instance_types = ["Standard_D8as_v5"]
   }
   
   variable "cluster_name"                    { type = string }
   variable "resource_group_name"             { type = string }
   variable "key_vault_name"                  { type = string }
   
   variable "key_vault_resource_group_name" {
     type    = string
     default = ""
   }
   
   variable "fips" {
     type        = bool
     description = "Use FIPS-enabled nodes for Karpenter. Set to false for standard mode."
     default     = true
   }
   
   variable "instance_types" {
     type    = list(string)
     default = ["Standard_D8ps_v5"]
   }
   
   variable "arch" {
     type        = string
     description = "CPU architecture for Karpenter nodes. Use 'amd64' or 'arm64'."
     default     = null
   
     validation {
       condition     = var.arch == null || contains(["amd64", "arm64"], var.arch)
       error_message = "arch must be 'amd64' or 'arm64'."
     }
   }
   
   output "helm_install" {
     value = module.policy_workbench.helm_install
   }
   

   To use an existing Managed HSM instead of a Standard or Premium Key Vault, replace the keystore block with the following code block:

   azure_keystore = {
     type                = "managed_hsm"
     name                = "<managed-hsm-name>"
     resource_group_name = "<hsm-resource-group-name>" # omit if same as resource_group_name
   }
   

In the main.tf file, specify the values of the following parameters:

3. Configure OCI registry credentials as described in Configuring Credentials for the Policy Workbench.

4. Run the following commands to plan and install the Policy Workbench OpenTofu module:

   tofu init
   
   # Default deployment (ARM64 + FIPS)
   tofu plan \
     -var="cluster_name=<cluster-name>" \
     -var="resource_group_name=<aks-resource_group_name>" \
     -var="key_vault_name=<key-vault-name>"
   
   tofu apply \
     -var="cluster_name=<cluster-name>" \
     -var="resource_group_name=<aks-resource_group_name>" \
     -var="key_vault_name=<key-vault-name>"
   

   To deploy on amd64 (x86) nodes instead, set arch and instance_types in both the tofu plan and tofu apply commands:

   # AMD64 deployment (add -var="fips=false" to disable FIPS)
   tofu plan \
     -var="cluster_name=<cluster-name>" \
     -var="resource_group_name=<aks-resource_group_name>" \
     -var="key_vault_name=<key-vault-name>" \
     -var="arch=amd64" \
     -var='instance_types=["Standard_D8as_v5"]'
   
   tofu apply \
     -var="cluster_name=<cluster-name>" \
     -var="resource_group_name=<aks-resource_group_name>" \
     -var="key_vault_name=<key-vault-name>" \
     -var="arch=amd64" \
     -var='instance_types=["Standard_D8as_v5"]'
   

   If the Key Vault is in a different resource group, include the following variable:

   -var="key_vault_resource_group_name=<key-vault-resource-group-name>"
   

   To override the default Karpenter instance type, include the following variable:

   -var='instance_types=["<instance-type>"]'
   

   To override the default secure mode, include the following variable:

   -var="fips=false"
   

   For the values of cluster_name, resource_group_name, key_vault_name, fips, arch, instance_types, and key_vault_resource_group_name, refer to the parameter table in step 2.

   OpenTofu prints the plan and prompts for confirmation. Enter yes to proceed. To skip the prompt, add the -auto-approve option to the commands.

After completing this procedure, refer to Deploy Policy Workbench with Helm to continue with the installation.

Installing Policy Workbench when root module is available

Install the Policy Workbench using the following steps:

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.

1. Add the following module block to the existing root module:

   module "policy_workbench" {
     source = "oci://<Container_Registry_Path>/policy-workbench/opentofu/modules/policy-workbench/azure?tag=<version>"
   
     cluster_name                    = "<aks-cluster-name>"
     oci_host                        = "<Container_Registry_Path>"
     resource_group_name             = "<resource-group>"
   
     azure_keystore = {
       type                = "key_vault"
       name                = "<key-vault-name>"
       resource_group_name = "<key-vault-resource-group>" # omit if same as resource_group_name
     }
     # Optional overrides; set these module arguments before planning:
     # fips = false
     # arch = "amd64"
     # instance_types = ["Standard_D8as_v5"]
   }
   

   To use an existing Managed HSM instead of a Standard or Premium Key Vault, replace the keystore block with the following code block:

   azure_keystore = {
     type                = "managed_hsm"
     name                = "<managed-hsm-name>"
     resource_group_name = "<hsm-resource-group-name>" # omit if same as resource_group_name
   }
   

   For more information about adding a module to an existing root module, refer to Module Blocks in the OpenTofu documentation.

   Set the value of version in the main.tf file as specified in the parameters table.

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

   • hashicorp/azurerm version ~> 5.7
   • hashicorp/kubernetes version ~> 2.35

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

3. If the root module does not configure the Azure provider with resource_provider_registrations = "none", add the following code block to avoid requiring subscription-level registration permissions:

   provider "azurerm" {
     features {}
     resource_provider_registrations = "none"
   }
   

4. Configure the Kubernetes provider to connect to the target AKS cluster by adding the following code block:

   data "azurerm_kubernetes_cluster" "this" {
     name                = "<aks-cluster-name>"
     resource_group_name = "<resource-group>"
   }
   
   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)
   }
   

5. Configure OCI registry credentials as described in Configuring Credentials for the Policy Workbench.

6. Navigate to the directory containing the root module.

7. Replace the cluster, resource group, and keystore placeholders in the data and module blocks. To change architecture, VM size, or FIPS mode, edit the corresponding module arguments before planning.

8. Run the following commands from the root-module directory:

   tofu init
   tofu plan
   tofu apply
   

   OpenTofu prints the plan and prompts for confirmation. Enter yes to proceed. To skip the prompt, add the -auto-approve option to the commands.

After completing this procedure, refer to Deploy Policy Workbench with Helm to continue with the installation.

Self-managed Workbench resources

Use this path when the existing infrastructure process manages Workbench resources instead of the policy-workbench OpenTofu module. This path does not require OpenTofu commands. After completing the prerequisites and configuration below, install the chart using the shared Helm procedure.

Self-managed prerequisites

• Ensure that the target AKS cluster has a supported PPC installation and is accessible. For more information on deploying PPC onto an existing AKS cluster, refer to In-cluster PPC deployment.
• Ensure that Azure CLI access and permissions are available to configure a user-assigned managed identity, federated identity credential, and Key Vault or Managed HSM role assignment.
• Identify the Key Vault or Managed HSM to use and the StorageClass and node scheduling requirements for the Workbench workloads.

Self-managed node resources and scheduling

If nodes are provisioned manually instead of using the provided Karpenter modules, size them to cover the Policy Workbench footprint.

Where Karpenter is configured, it can provision additional nodes as workloads need them. Otherwise, ensure the cluster has enough capacity to run Policy Workbench and other workloads.

Azure KMS Backend Resources for KMGW

The following resources must be provisioned manually:

• User-assigned managed identity.
• Federated identity credential.
• Key Vault or Managed HSM role assignment.

The following table lists the required role assignment for each keystore type:

The Helm chart expects kmgw to run as the ServiceAccount configured by keystore.serviceAccount.name.

Configuring Persistent Storage

Policy Workbench uses the default StorageClass of the cluster unless pvc.storageClassName is set. Verify the StorageClasses available in the target AKS cluster before installation.

1. Run the following command to list the StorageClasses in the cluster:

   kubectl get storageclass
   

2. If the cluster has no default StorageClass, or the default is not suitable for Policy Workbench, set the StorageClass name in the Helm values file, policy-workbench-values.yaml.

   pvc:
     storageClassName: "<storage-class-name>"
   

   For example, PPC normally creates a StorageClass named pty-sc.

   Note: Without a suitable default StorageClass, the Policy Workbench PVCs remain unbound. Due to which the StatefulSet pods cannot be scheduled. Retain this setting in the policy-workbench-values.yaml file used for installation and future upgrades.

Configuring Node Selection for Policy Workbench Pods

By default, Kubernetes can schedule Policy Workbench pods on any available node. To pin Policy Workbench pods to specific nodes in the target AKS cluster, perform the following steps:

1. Run the following command to apply the policy-workbench label to each node where Policy Workbench pods will be scheduled:

   kubectl label node <node-name> nodepool.protegrity.com/name=policy-workbench
   

   Replace <node-name> with the name of the target node. Repeat the command for each node.

2. In the policy-workbench-values.yaml file, add a nodeSelector entry under scheduling that matches the label applied in the previous step:

   scheduling:
     nodeSelector:
       nodepool.protegrity.com/name: policy-workbench
   

3. If the target nodes have taints applied, apply a PreferNoSchedule taint and a matching toleration.

   Important: Use PreferNoSchedule, not NoSchedule. Velero backup and restore pods do not inherit the tolerations set for Policy Workbench. A NoSchedule taint on the workbench nodes blocks Velero restores.

   a. Run the following command to apply the taint on each target node:

   kubectl taint node <node-name> workload=policy-workbench:PreferNoSchedule
   

   b. Add the matching toleration under scheduling.tolerations in the policy-workbench-values.yaml file. The key, value, and effect must match the taint applied to the node:

   scheduling:
     tolerations:
       - key: "workload"
         operator: "Equal"
         value: "policy-workbench"
         effect: "PreferNoSchedule"
   

Applying Scheduling to Individual Services

To apply a different scheduling policy to a specific service instead of all services, add a scheduling block under the key for that service.

For example:

rpproxy:
  replicas: 3
  scheduling:
    topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: rpproxy

Here, the Resilient Package Proxy or rpproxy, which delivers packages to Protectors, is the only service whose replica count can be scaled. By default, rpproxy runs with one replica. This example increases the rpproxy replica count from one to three. Add a topologySpreadConstraint to spread the replicas across nodes, so that a single node failure does not take down every replica:

Note: When increasing the replica count, ensure the cluster has sufficient capacity to meet the higher minimum resource requirements.

The whenUnsatisfiable field accepts one of the following values:

• ScheduleAnyway: Spreads pods on a best-effort basis without blocking scheduling if the constraint cannot be satisfied.
• DoNotSchedule: Leaves a pod in Pending state rather than placing it on a node that violates the spread constraint.

Configuring the AKS Backend and Helm Values

On the jump box, perform the following steps to set up the KMGW managed identity and configure the policy-workbench-values.yamlfile:

1. Set the environment variables used by the following commands:

   export RESOURCE_GROUP="<resource-group>"
   export CLUSTER_NAME="<cluster-name>"
   export LOCATION="<region>"           # for example, eastus
   export IDENTITY_NAME="aks-${CLUSTER_NAME}-policy-workbench-kmgw-identity"
   export NAMESPACE="policy-workbench"
   export SERVICE_ACCOUNT="workbench-kms"
   export KEY_VAULT_NAME="<key-vault-name>" # set for the Key Vault branch
   export HSM_NAME="<managed-hsm-name>"      # set for the Managed HSM branch
   

2. If OIDC Issuer and Workload Identity are not enabled on the AKS cluster, run the following command to enable them:

   az aks update \
     --resource-group "$RESOURCE_GROUP" \
     --name "$CLUSTER_NAME" \
     --enable-oidc-issuer \
     --enable-workload-identity
   

   Warning: Enabling OIDC Issuer and Workload Identity triggers an AKS cluster update. Once enabled, these features cannot be disabled.

3. Run the following command to create the user-assigned managed identity and capture its client and principal IDs:

   az identity create \
     --name "$IDENTITY_NAME" \
     --resource-group "$RESOURCE_GROUP" \
     --location "$LOCATION"
   
   export IDENTITY_CLIENT_ID=$(az identity show -g "$RESOURCE_GROUP" -n "$IDENTITY_NAME" --query clientId -o tsv)
   export IDENTITY_PRINCIPAL_ID=$(az identity show -g "$RESOURCE_GROUP" -n "$IDENTITY_NAME" --query principalId -o tsv)
   

4. Run the following command to retrieve the AKS OIDC issuer URL:

   export OIDC_ISSUER=$(az aks show -g "$RESOURCE_GROUP" -n "$CLUSTER_NAME" --query oidcIssuerProfile.issuerUrl -o tsv)
   

5. Run the following command to bind the federated identity credential to the Helm release namespace and ServiceAccount:

   az identity federated-credential create \
     --name "aks-${CLUSTER_NAME}-policy-workbench-kmgw-federated" \
     --identity-name "$IDENTITY_NAME" \
     --resource-group "$RESOURCE_GROUP" \
     --issuer "$OIDC_ISSUER" \
     --subject "system:serviceaccount:${NAMESPACE}:${SERVICE_ACCOUNT}" \
     --audience api://AzureADTokenExchange
   

   The --subject and --audience values must remain exactly as shown.

6. Choose the role-assignment branch for the configured keystore.

   Azure Key Vault Standard or Premium

   Run the following commands to assign the managed identity the Key Vault Crypto Officer role and retrieve the vault URI:

   export KEY_VAULT_ID=$(az keyvault show -g "$RESOURCE_GROUP" -n "$KEY_VAULT_NAME" --query id -o tsv)
   
   az role assignment create \
     --assignee-object-id "$IDENTITY_PRINCIPAL_ID" \
     --assignee-principal-type ServicePrincipal \
     --role "Key Vault Crypto Officer" \
     --scope "$KEY_VAULT_ID"
   
   export KEYSTORE_URI=$(az keyvault show -g "$RESOURCE_GROUP" -n "$KEY_VAULT_NAME" --query properties.vaultUri -o tsv)
   
   echo "Managed identity client ID: $IDENTITY_CLIENT_ID"
   echo "Key Vault URI: $KEYSTORE_URI"
   

   Azure Managed HSM

   Run the following commands to assign the managed identity the Managed HSM Crypto User role and retrieve the HSM URI:

   az keyvault role assignment create \
     --hsm-name "$HSM_NAME" \
     --assignee-object-id "$IDENTITY_PRINCIPAL_ID" \
     --role "Managed HSM Crypto User" \
     --scope /
   
   export KEYSTORE_URI=$(az keyvault show --hsm-name "$HSM_NAME" --query properties.hsmUri -o tsv)
   
   echo "Managed identity client ID: $IDENTITY_CLIENT_ID"
   echo "Managed HSM URI: $KEYSTORE_URI"
   

7. Add the keystore settings to policy-workbench-values.yaml using the IDENTITY_CLIENT_ID and KEYSTORE_URI captured in the selected branch:

   keystore:
     backend: azure
     serviceAccount:
       name: workbench-kms
     azure:
       vaultUri: <key-vault-or-managed-hsm-uri>
       clientId: <managed-identity-client-id>
   

   For Azure Key Vault Standard or Premium only, enable software-generated random bytes by adding softwareRandomEnabled: true under keystore.azure:

   keystore:
     backend: azure
     serviceAccount:
       name: workbench-kms
     azure:
       vaultUri: <key-vault-uri>
       clientId: <managed-identity-client-id>
       softwareRandomEnabled: true
   

   Warning: Azure Key Vault Standard and Premium do not provide random bytes from a KMS or HSM backend. When using Key Vault, kmgw uses software-generated random bytes. Use Managed HSM if random bytes must come from an HSM-backed service.

Deploy Policy Workbench with Helm

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.

After completing either resource-preparation path, install Policy Workbench with Helm.

• Self-managed resources: Configure the policy-workbench-values.yaml file with the storage, scheduling, and keystore settings described in Self-managed workbench resources.
• Module-managed resources: The OpenTofu module generates the policy-workbench-values.yaml file with the required resource settings. The tofu output -raw helm_install command prints a ready-to-run Helm command with the version and namespace values filled in.

Set <version> to the Policy Workbench version being installed. If the namespace was overridden in the OpenTofu module, use the same namespace in the Helm command. Retain the values file for future upgrades.

1. Run the following command to complete the installation of the Policy Workbench using Helm:

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

   In the command, specify the value of the following variable.

   Variable Name	Description	Value
   <version>	Tag version of the Policy Workbench, as specified in the product part number. Obtain the product part number from the Policy Workbench Readme.	1.13.1

2. Run the following command to view the pods created in the policy-workbench namespace:

   kubectl get pods -n policy-workbench
   

   The following output appears:

   NAME                        READY   STATUS    RESTARTS   AGE
   bootstrap-bffb4b5d9-v6ww4   1/1     Running   0          13m
   cert-7b88dcd84-zx7cv        1/1     Running   0          13m
   devops-75755d87d4-qw9n6     1/1     Running   0          13m
   hubcontroller-0             1/1     Running   0          13m
   kmgw-0                      1/1     Running   0          13m
   mbs-6b7dc765dd-brrfk        1/1     Running   0          13m
   repository-0                1/1     Running   0          13m
   rpproxy-79fc498d8-qp4fz     1/1     Running   0          13m
   rps-8d79b7d98-svhdw         1/1     Running   0          13m
   

   The number of rpproxy pods matches rpproxy.replicas if that value is overridden. Immediately after installation, the short-lived hubcontroller-init-* init job and kmgw-create-keystore-* pod may also appear.

Validating the deployment

Before validating the deployment of the Policy Workbench, ensure that the kubectl context is set to the target PPC cluster.

Note: The curl examples below assume that the server’s TLS certificate can be successfully verified. Do not use -k or --insecure in production, as these options disable certificate verification. For services using a private or self-signed CA, distribute the CA certificate to the client through a separate trusted channel and either install it in the client’s trusted certificate store or specify the CA certificate directly using curl --cacert.

Run kubectl config current-context to verify the current context. Run kubectl config use-context <context-name> to switch the context.

After installation, validate the Policy Workbench deployment using the following steps.

1. Run the following commands to retrieve the gateway host details and generate an admin JWT token:

Note: The admin user must change the default password on first login. Replace <password> with the new admin password.

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

TOKEN=$(curl --silent --show-error --dump-header - --output /dev/null "https://$GW_HOST/pty/v1/auth/login/token" \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'loginname=admin' \
  -d 'password=<password>' | grep -i 'pty_access_jwt_token:' | sed 's/pty_access_jwt_token: //' | tr -d '\r')

2. Create a workbench user using the following command:

curl --silent --show-error -X POST "https://$GW_HOST/pty/v1/auth/users" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "workbench",
    "password": "<password>",
    "roles": [
      "workbench_administrator",
      "security_administrator"
    ]
  }'

Note: The password policy requires a minimum of 14 characters, including at least one digit, one uppercase letter, one lowercase letter, and one special character.

3. Run the following command to get a token for the workbench user:

TOKEN=$(curl --silent --show-error --dump-header - --output /dev/null "https://$GW_HOST/pty/v1/auth/login/token" \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'loginname=workbench' \
  -d 'password=<password>' | grep -i 'pty_access_jwt_token:' | sed 's/pty_access_jwt_token: //' | tr -d '\r')

4. Run the Policy Management REST API to get datastores:

curl --silent --show-error "https://$GW_HOST/pty/v2/pim/datastores" \
  -H "Authorization: Bearer $TOKEN"

The expected output is []. This indicates that the Policy Workbench is initialized but the datastore is not yet created.

For more information about the workbench_administrator permissions, refer to Workbench Roles and Permissions.