Architecture and Components using 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 REST Container with static deployment on a Kubernetes cluster.

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 REST protector reads the policy package from the tmpfs directory.

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

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 and store the decrypted DEK in the cache.

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