Architecture and Components using Static Deployment

Describes the deployment, the individual components, and the workflow of the Protegrity Application Protector Java Container product integrated with static deployment.

Key features of a Static-based deployment include:

  • The deployments can be used in use cases where a fixed policy package is required.
  • The policy updates need to be triggered through automation using ConfigMap updates.

The following figure represents the architecture for deploying the Application Protector Java Container with static deployment on a Kubernetes cluster.

Workflow for the Application Protector Java Container Integration with RPP

Deployment Steps:

  1. The ESA administrator user pulls the policy package from the ESA and stores it to an Object Store or a Volume Mount.

  2. The Policy Loader sidecar container reads the internal configmap for policy updates.

  3. The sidecar container retrieves the policy package from the Object Store or Volume Mount.

  4. The sidecar container then stores the policy package in the tmpfs directory.

  5. The Application Protector Java Container protector reads the policy package from the tmpfs directory.

  6. Based on the values specified in the internal config.ini file, the protector initiates the RP Callback.

  7. The RP Callback decrypts the Data Encryption Key (DEK) using the KMS Proxy container.

  8. The KMS Proxy container reads the decrypted DEK from the cache, if present.

  9. If the DEK is not present in the cache, the KMS Proxy container uses the KMS Backend to retrieve the DEK from the Cloud KMS. The KMS Proxy container then stores the decrypted DEK in the cache.

  10. The Protector decrypts the policy package using the DEK and initializes its internal library.


Last modified : December 18, 2025