Protegrity Policy Manager on

Prerequisites for Installing the Policy Workbench

Mon, 01 Jan 0001 00:00:00 +0000

Ensure that the jumpbox can connect to the required repositories. If not already authenticated, then log in to the required repository.

For connecting and deploying from the Protegrity Container Registry (PCR), use the following command and the credentials obtained from the My.Protegrity portal during account creation:

helm registry login registry.protegrity.com:9443

For connecting and deploying to the local repository, use your local credentials and local repository endpoint as required.

Ensure that the PPC Cluster is installed and accessible, before installing Policy Workbench on PPC.

Uninstalling the Protegrity Policy Manager

Mon, 01 Jan 0001 00:00:00 +0000

To uninstall the deployment:

Run the following command to uninstall the Policy Workbench.

helm uninstall policy-workbench -n policy-workbench

Run the following command to clean up the AWS resources.

tofu destroy -var='cluster_name=<PPC cluster name>'

Backing up the Policy Workbench

Mon, 01 Jan 0001 00:00:00 +0000

By default, the Policy Workbench data is backed up on a daily basis using a scheduled backup, after the Policy Workbench has been installed. The backed-up data includes the Kubernetes object state and the persistent volume data. The backed-up data is automatically stored in the encrypted AWS S3 bucket that you created when you deployed PPC.

For more information about the AWS S3 bucket, refer to the section Creating AWS KMS Key and S3 Bucket.

Restoring the Policy Workbench

Mon, 01 Jan 0001 00:00:00 +0000

Before you begin

Before starting a restore, ensure that the following prerequisites are met:

Ensure that an existing backup is available. Backups are taken automatically as part of the default installation of the Policy Workbench using scheduled backup mechanisms. The backups are available in the encrypted AWS S3 bucket that you created when you deployed PPC. You can also choose to manually back up the data.

For more information about the AWS S3 bucket, refer to the section Creating AWS KMS Key and S3 Bucket.

Workbench Roles and Permissions

Mon, 01 Jan 0001 00:00:00 +0000

Roles are templates that include permissions and users can be assigned to one or more roles. All users in the appliance must be associated with a role.

The roles packaged with Policy Workbench are as follows:

Roles	Description	Permissions
workbench_administrator	Full administrative access to workbench.	workbench_management_policy_write, workbench_deployment_immutablepackage_export, workbench_deployment_certificate_export
workbench_viewer	Read-only access to workbench.	workbench_management_policy_read
workbench_deployment_administrator	Administrative access to workbench deployments.	workbench_deployment_immutablepackage_export, workbench_deployment_certificate_export

The capabilities of a role are defined by the permissions attached to the role. Though roles can be created, modified, or deleted from the appliance, permissions cannot be edited. The permissions that are available to map with a user and packaged with Policy Workbench as default permissions are as follows:

Troubleshooting the Protegrity Policy Manager

Mon, 01 Jan 0001 00:00:00 +0000

Helm upgrade fails due to existing Kubernetes jobs

Issue: Helm upgrade fails because existing jobs, such as hubcontroller-init and kmgw-create-keystore, cannot be patched.

Description: Helm upgrade cannot modify or replace existing Kubernetes jobs if fields such as image registry, environment variables, args, and volumes are changed. This happens because the pod template of a job is immutable. So, the existing pods cannot be replaced when their template changes. As a result, the Helm upgrade fails.