REST Container on

Using Samples

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

Protegrity delivers a sample application as part of the REST Container installation package. The sample application consists of the following items:

Policy package.
Sample Postman collection (to test AP-REST Container Pods serving deployed IMP).
Autoscaling script (to push more load to the Kubernetes cluster to force autoscaling of the AP-REST Container Pods).

Run this sample application end-to-end, as a sanity test. This will enable them to confirm that the installation was completed accurately. In this section are details on the exact steps a customer must follow to run the sample application end-to-end. Those details explain usage of the components included in REST-Samples_Linux-ALL-ALL_x86-64_<AP-REST_version>.tgz archive.

Running the Autoscaling Script

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

The Autoscaling script is used to issue continuous requests on the AP-REST containers. When the number of REST requests hitting the container are increased, with Horizontal Pod Autoscaling, Kubernetes automatically scales the number of pods based on the CPU utilization observed.

The user can run the autoscaling script from any Linux node, which can connect the external IP for the deployment.

Usage

./Sample_App_autoscale.sh <Ingress address> <CA certificate path> <Client certificate path> <Client key path> <version_endpoint>

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 REST 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: