Application Protector Java Container on

Running Security Operations

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

This section describes how you can use the Sample Application instances running on the Kubernetes cluster to protect the data that is sent by a REST API client.

To run security operations:

Send the following CURL request from the Linux instance.

curl --location --request POST 'http://<DNS name or IP address of the Load Balancer>:8080/protect' --header 'Content-Type: application/json' --header 'X-Correlation-ID: k81d1fae-7dec-41g0-a765-90a0c31e6wf5' --data-raw '{ "dataElement": "Alphanum", "policyUser": "user1", "input": [ "protegrity1234","helloworld" ] }' -v

The Application Protector Java Container instance returns the following protected output.

Upgrading the Protector from Version 9.x to 10.x

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

This section explains the steps and procedure to upgrade the Application Java Container protector from version 9.x to 10.x. This method is used for a major release upgrade. For example, this upgrade procedure is used in case of architectural changes.

Upgrade Approach

The 9.x and 10.x versions include different components and resource requirements as part of the deployment. As a result, the approach uses the following steps:

Create a 10.x setup in a different namespace.
Run test traffic to the 10.x setup to verify that the security operations are working.
Stop the traffic to the 9.x setup and make changes to point the traffic to the 10.x setup.
Switch the production traffic from the 9.x deployment to the 10.x deployment.

Before you begin

Ensure that you have access to the Kubernetes cluster with appropriate permissions. For more information about the required permissions, refer to the section Software Requirements.
Ensure that you have a separate directory structure for the 9.x and 10.x deployments.
Ensure that your container logs are accessible. These can be used to verify the deployment.
Ensure that the Container images for 10.x version are uploaded in the Container registry.
Ensure that the protector pods for the 9.x version are running and are in a healthy state.
Ensure that the required security policy is available on the 10.x ESA.

Upgrading the Protector in Dynamic Mode

Perform the following steps to upgrade the protector from 9.x to 10.x in dynamic mode.

Upgrading the Protector from Version 10.x to 10.y

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

This section explains the steps and procedure for performing a rolling upgrade and roll back on a Kubernetes deployment consisting of pods. This method is useful for maintenance releases such as bug fixes and CVE updates. In this method, the protector is upgraded from version 10.x to version 10.y.

Before you begin

Ensure that you have access to the Kubernetes cluster with appropriate permissions. For more information about the required permissions, refer to the section Software Requirements.
Ensure that you have a separate directory structure for the 10.x and 10.y deployments.
Ensure that your container logs are accessible. These can be used to verify the deployment.
Ensure that the Container images for 10.y version are uploaded in the Container registry.
Ensure that the protector pods for the 10.x version are running and are in a healthy state.
Ensure that the required security policy is available on the 10.y ESA.

Rolling Upgrade Steps for Dynamic Deployment

This section explains how to perform a rolling upgrade for dynamic deployment.

Using Dockerfiles to Build Custom Images

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

Protegrity base images use the default RHEL Universal Base Image. Using Dockerfiles, you can use a base image of your choice.

To create custom image:

Download the installation package.

For more information about downloading the installation package, refer to the section Extracting the Installation Package.

Important: The dependency packages required for building the Docker images are specified in the HOW-TO-BUILD file, which is a part of the installation package. You must ensure that these dependency packages can be downloaded either from the Internet or from your internal repository.

Appendix - Deploying the Helm Charts by Using the Set Argument

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

To deploy Helm charts using the set argument:

Navigate to the directory where you have stored the values.yaml file for deploying the corresponding Helm chart.
Deploy the Helm chart using the following command.

 helm install <name for this helm deployment> <Location of the directory that contains the Helm chart> -n <Namespace>
 --set <tag 1>="Value 1"
 --set <tag 2>="Value 2"
 --set <tag 3>="Value 3"
 --set <tag 4>="Value 4"

For example: