This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Preparing the Environment

Preparing the environment for deploying the protector.

This section provides an overview of the steps required to prepare the environment for deploying the Application Protector Java Container product.

1 - Initializing the Jump Box

Initialize the Linux instance.

The Linux instance should be connected to the Kubernetes cluster. The following is the minimum system requirements to be configured for a Linux instance.

Software and Files Required for the Linux instancePurposeLink
DockerLoad the images into the repositoryInstall Docker Engine
HelmInstall Helm ChartsInstall Helm
KubectlConnect to the Kubernetes clusterKubectl reference
AWS CLIManage AWS servicesAWS Command Line Interface

2 - Extracting the Installation Package

Extract the AP Java Container installation package.

This section describes the steps to download and extract the installation package for the Application Protector Java Container.

To download the installation package:

  1. Download the ApplicationProtector_RHUBI-9-64_x86-64_Generic.K8S.JRE-<JRE_Version>_<Version>.tgz file on the Linux instance.

  2. Run the following command to extract the files from the ApplicationProtector_RHUBI-9-64_x86-64_Generic.K8S.JRE-<JRE_Version>_<Version>.tgz file.

    tar -xvf ApplicationProtector_RHUBI-9-64_x86-64_Generic.K8S.JRE-<JRE_Version>_<Version>.tgz

    The signatures directory and the ApplicationProtector_RHUBI-9-64_x86-64_Generic.K8S.JRE-<JRE_Version>_<Version>.tgzfileare extracted.

  3. Run the following command to extract the files from the ApplicationProtector_RHUBI-9-64_x86-64_Generic.K8S.JRE-<JRE_Version>_<Version>.tgz file.

    tar -xvf ApplicationProtector_RHUBI-9-64_x86-64_Generic.K8S.JRE-<JRE_Version>_<Version>.tgz

    The following directories and files are extracted:

    • devops - Helm charts, Dockerfiles, and container images to deploy the Application Protector Java Container using the Static policy.
    • protector - Dockerfiles and container images to create the Application Protector Java Container.
    • dynamic - Helm charts, Dockerfiles, and container images to deploy the Application Protector Java Container using the Dynamic method.
    • common - Helm charts, Dockerfiles, and container images to deploy the Log Forwarder.
    • certs - Create certificates required for secure communication.
    • HOW-TO-BUILD-DOCKER-IMAGES - Text file specifying how to build the Docker images.
    • manifest.json - Metadata file specifying the product version and component names.

The following shows a list of the Helm charts and container images.

Package NameDescriptionDirectory
ApplicationProtector-SAMPLE-APP_DYNAMIC-HELM_ALL-ALL-ALL_x86-64_K8S_<Version>.tgzPackage containing the Helm chart used to deploy the Sample Application Container.dynamic
RPPROXY_RHUBI-9-64_x86-64_K8S_<Version>.tar.gzUsed to set up the RPProxy container.dynamic
RPPROXY_SRC_<Version>.tgzPackage containing the Dockerfile that can be used to create a custom image for the RPProxy container.dynamic
RPPROXY-HELM_ALL-ALL-ALL_x86-64_K8S_<Version>.tgzPackage containing the Helm chart used to deploy the RPProxy container.dynamic
KMSPROXY_RHUBI-9-64_x86-64_K8S_<Version>.tar.gzUsed to create the KMSProxy container.devops
KMSPROXY_SRC_<Version>.tgzPackage containing the Dockerfile that can be used to create a custom image for the KMSProxy container and the associated binary files.devops
KMSPROXY-HELM_ALL-ALL-ALL_x86-64_K8S_<Version>.tgzPackage containing the Helm chart used to deploy the KMSProxy container.devops
POLICY-LOADER_RHUBI-9-64_x86-64_K8S_<Version>.tar.gzUsed to create the Policy Loader container.devops
POLICY-LOADER_SRC_<Version>.tgzPackage containing the Dockerfile that can be used to create a custom image for the Policy Loader container and the associated binary files.devops
ApplicationProtector-SAMPLE-APP_DEVOPS-HELM_ALL-ALL-ALL_x86-64_K8S_<Version>.0.tgzPackage containing the Helm chart used to deploy the Sample Application Container.devops
ApplicationProtector-SAMPLE-APP_SRC_<Version>.tgzPackage containing the Dockerfile that can be used to create a custom image for the Sample Application Container and the associate binary files.protector
LOGFORWARDER_RHUBI-9-64_x86-64_K8S_<Version>.tar.gzUsed to create the Log Forwarder container.common
LOGFORWARDER_SRC_<Version>.tgzPackage containing the Dockerfile that can be used to create a custom image for the Log Forwarder container and the associated binary files.common
LOGFORWARDER-HELM_ALL-ALL-ALL_x86-64_K8S_<Version>.tgzPackage containing the Helm chart used to deploy the Log Forwarder container.common

3 - Creating Certificates

Certificate creation

This section describes the steps to create certificates required for secure communication. These certificates are for secure communication between:

  • ESA and the RPP.
  • RPP and the protector.
  • KMSProxy and the protector.

To download the installation package:

  1. Navigate to the directory where you have extracted the installation package.

  2. Navigate to the certs directory. The following files are available:

    • CertificatesSetup_Linux_x64_<Version>tgz - Download the certificates from the ESA. You can use them as the common certificates in the dynamic deployment between the RPProxy and the ESA, and between the RPProxy and the protector. You can also use these certificates separately as the upstream certificate between the ESA and RPProxy in the dynamic deployment.
    • CreateCertificate_Linux_x64_<Version>.tgz - Generate self-signed client and server certificates. In the Dynamic method, these certificates are used for communication between RPProxy and the protector. In the Static policy method, these certificates are used for communication between KMSProxy and the protector. Customers can choose to use their own certificates.
  3. Extract both the packages using the following command.

    tar -xvf CertificatesSetup_Linux_x64_<Version>.tgz
    tar -xvf CreateCertificate_Linux_x64_<Version>.tgz
    

    The following files are extracted:

    • CertificatesSetup_Linux_x64_<Version>.sh
    • CreateCertificate_Linux_x64_<Version>.sh

Certificates for communication between the ESA and the RPP

  1. Run the following command to create ESA certificates for establishing a secure communication between the ESA and the RPP.
./CertificatesSetup_Linux_x64_<Version>.sh (-u <username> -p <password>) [-h <hostname>] [--port <port>] [-d <directory>]

Options:
  -u      User with the Export Certificates role
  -p      Password for user with the Export Certificates role
  -h      Host or IP address of the ESA
  --port  Port number of the ESA
  -d      local directory where certificates are stored

For more information about the command, use the –help parameter as shown in the following command.

./CertificatesSetup_Linux_x64_<Version>.sh --help

The output displays all the options that can be used with the command. It also provides usage examples.

Certificates for client and server communication between RPP and Protector, and KMS-Proxy and Protector

  1. Run the following command to create server-side certificates.
./CreateCertificate_Linux_x64_<Version>.sh (client | server ) --name <common name> [--dir <directory> ] [--dns <dnsname>] [--ip <ip address>] 

Options:
  client        Generate client certificate
  server        Generate server certificate
  --name        Certificate common name.
  --dns         Specify domain names. To specify multiple DNS names, repeat the --dns flag.
  --ip          Specify IP addresses. To specify multiple IP address, repeat the --ip flag.
  --noenc       The certificate key file is not encrypted. No secret.txt file created.
  --dir         Output base directory for certificates.
  --print       Prints OpenSSL configuration files used to generate certificates.
  --help        Print help message.

This command is used to create the certificates for both the Dynamic and Static-based deployments.

For more information about the command, use the –help parameter as shown in the following command.

./CreateCertificate_Linux_x64_<Version>.sh --help

The output displays all the options that can be used with the command. It also provides usage examples.

4 - Uploading the Images to the Container Repository

Describes uploading the RPProxy, Policy Loader, KMSProxy, and AP Java Container images to the Container Repository.

Before you begin, ensure that you have set up your Container Registry.

To upload the images to the Container Repository:

  1. Install Docker on the Linux instance.

    For more information about installing Docker on a Linux machine, refer to the Docker documentation.

  2. Run the following command to authenticate your Docker client to Amazon ECR.

    aws ecr get-login-password --region <Name of ECR region where you want to upload the container image> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<Name of ECR region where you want to upload the container image>.amazonaws.com

    For more information about authenticating your Docker client to Amazon ECR, refer to the AWS CLI Command Reference documentation.

  3. Extract the installation package.

    The RPProxy, Policy Loader, and KMSProxy container images are extracted.

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

  4. Perform the following steps to upload the AP Java container image to Amazon ECR.

    a. Build a custom image for the AP Java container.

    For more information about creating custom images, refer to the section Using Dockerfiles to Build Custom Images.

    Note: This step is not required for the RPProxy, Policy Loader, and KMSProxy containers as the container images are available in the installation package.

    b. Run the following command to load the AP Java container image into Docker.

    docker load -i APJAVA_RHUBI-9-64_x86-64_K8S_<Version>.tar.gz

    c. Run the following command to list the AP Java container image.

    docker images

    d. Tag the image to the Amazon ECR by running the following command.

    docker tag <Container image>:<Tag> <Container registry path>/<Container image>:<Tag>

    For example:

    docker tag apjava:AWS <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/apjava:AWS

    For more information regarding tagging an image, refer to the section Pushing an image in the AWS documentation.

    e. Push the tagged image to the Amazon ECR by running the following command.

    docker push <Container registry path>/<Container image>:<Tag>

    For example:

    docker push <aws_account_id>.dkr.ecr.us-east-1.amazonaws.com/apjava:AWS

  5. Navigate to the directory where you have extracted the Helm charts packages for the AP Java containers.

  6. In the values.yaml file, update the appropriate path for the springappImage setting, along with the tag.

  7. Repeat steps 1 to 6 for uploading the respective images for RPProxy, Policy Loader, and KMSProxy.

5 - Creating the AWS Environment

Overview of creating the AWS environment.

This section describes how to create the AWS runtime environment.

Prerequisites

Before creating the runtime environment on AWS, ensure that you have a valid AWS account and the following information:

  • Login URL for the AWS account
  • Authentication credentials for the AWS account

Audience

It is recommended that you have working knowledge of AWS and knowledge of the following concepts:

  • Introduction to AWS S3
  • Introduction to AWS Cloud Security
  • Introduction to AWS EKS

5.1 - Creating the AWS Setup for Static Mode

Overview of creating the AWS setup for static mode.

This section describes how to create the following AWS resources for static mode:

  • Data Encryption Key
  • AWS S3 bucket
  • AWS EFS

5.1.1 - Creating a Data Encryption Key (DEK)

This section describes how to create the Data Encryption Key. This key is the AWS customer master key that is used to encrypt the policy package.

To create a Data Encryption Key:

  1. Log in to the AWS environment.
  1. Navigate to Services.

    A list of AWS services appears.

  2. In Security, Identity, & Compliance, click Key Management Service.

    The AWS Key Management Service (KMS) console opens. By default, the Customer managed keys screen appears.

  3. Click Create key.

    The Configure key screen appears.

  4. In the Key type section, select the Asymmetric option to create a single customer master key that will be used to perform the encrypt and decrypt operations.

  5. In the Key usage section, select the Encrypt and decrypt option.

  6. In the Key spec section, select one option.

    For example, select RSA_4096.

  7. In the Advanced options section, select the Single-Region Key option.

  8. Click Next.

    The Add labels screen appears.

  9. In the Alias field, specify the display name for the key, and then click Next.

    The Review and edit key policy screen appears.

  10. Click Finish.

    The Customer managed keys screen appears, displaying the newly created customer master key.

  11. Click the key alias.

    A screen specifying the configuration for the selected key appears.

  12. In the General Configuration section, copy the value specified in the ARN field, and save it on your local machine.

    You need to attach the key to the KMSDecryptAccess policy. You also need to specify this ARN value in the command for creating a Kubernetes secret for the key.

  13. Navigate to Services > IAM.

  14. Click Policies.

    The Policies screen appears.

  15. Select the KMSDecryptAccess policy.

    The Permissions tab appears.

  16. Click Edit policy to edit the policy in JSON format.

  17. Modify the policy to add the ARN of the key that you have copied in step 13 to the Resource parameter.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "VisualEditor0",
                "Effect": "Allow",
                "Action": "kms:Decrypt",
                "Resource": [
                    "<ARN of the AWS Customer Master Key>"
                ]
            }
        ]
    }
    
  18. Click Review policy, and then click Save changes to save the changes to the policy.

5.1.2 - Creating an AWS S3 Bucket

This section describes how to create an AWS S3 bucket.

Important: This procedure is optional and is required only if you want to use AWS S3 for storing the policy snapshot during static deployment, instead of the persistent volume.

To create an AWS S3 bucket:

  1. Login to the AWS environment.
  1. Navigate to Services.

    A list of AWS services appears.

  2. In Storage, click S3.

    The S3 buckets screen appears.

  3. Click Create bucket.

    The Create bucket screen appears.

  4. In the General configuration screen, specify the following details.

    1. In the Bucket name field, enter a unique name for the bucket.

    2. In the AWS Region field, choose the same region in which you want to create your EC2 instance.

    If you want to configure your bucket or set any specific permissions, then you can specify the required values in the remaining sections of the screen. Otherwise, you can go directly to the next step to create a bucket.

  5. Click Create bucket.

    The bucket is created.

5.1.3 - Creating an AWS EFS

This section describes how to create an AWS EFS.

Important: This procedure is optional and is required only if you want to use AWS EFS for storing the policy package during static deployment, instead of AWS S3.

To create an AWS EFS:

  1. Login to the AWS environment.
  1. Navigate to Services.

    A list of AWS services appears.

  2. In Storage, click EFS.

    The File Systems screen appears.

  3. Click Create file system.

    The Configure network access screen appears.

  4. In the VPC list, select the VPC where you will be creating the Kubernetes cluster.

  5. Click Next Step.

    The Configure file system settings screen appears.

  6. Click Next Step.

    The Configure client access screen appears.

  7. Click Next Step.

    The Review and create screen appears.

  8. Click Create File System.

    The file system is created.

    Note the value in the File System ID column. You need to specify this value as the value of the volumeHandle parameter in the pv.yaml file in step 10c.

  9. Perform the following steps if you want to use a persistent volume for storing the policy package instead of the AWS S3 bucket.

    a. Create a file named storage_class.yaml for creating an AWS EFS storage class.

    The following snippet shows the contents of the storage_class.yaml file.

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: efs-sc
      provisioner: efs.csi.aws.com
    

    Important: If you want to copy the contents of the storage_class.yaml file, then ensure that you indent the file as per YAML requirements.

    b. Run the following command to provision the AWS EFS using the storage_class.yaml file.

    kubectl apply -f storage_class.yaml

    An AWS EFS storage class is provisioned.

    c. Create a file named pv.yaml for creating a persistent volume resource.

    The following snippet shows the contents of the pv.yaml file.

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: efs-pv1
        labels:
          purpose: policy-store
      spec:
        capacity:
          storage: 1Gi
        volumeMode: Filesystem
        accessModes:
          - ReadWriteMany
        persistentVolumeReclaimPolicy: Retain
        storageClassName: **efs-sc**
        csi:
          driver: efs.csi.aws.com
          volumeHandle: **fs-618248e2:**/
    

    Important: If you want to copy the contents of the pv.yaml file, then ensure that you indent the file as per YAML requirements.

    This persistent volume resource is associated with the AWS EFS storage class that you have created in step 10b.

    In the storageClassName parameter, ensure that you specify the same name for the storage class that you specified in the storage_class.yaml file in step 10a.

    For example, specify efs-sc as the value of the storageClassName parameter.

    d. Run the following command to create the persistent volume resource.

    kubectl apply -f pv.yaml

    A persistent volume resource is created.

    e. Create a file named pvc.yaml for creating a claim on the persistent volume that you have created in step 10d.

    The following snippet shows the contents of the pvc.yaml file.

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: efs-claim1
      spec:
        selector:
          matchLabels:
            purpose: "policy-store"
        accessModes:
          - ReadWriteMany
        storageClassName: **efs-sc**
        resources:
          requests:
            storage: 1Gi
    

    Important: If you want to copy the contents of the pvc.yaml file, then ensure that you indent the file as per YAML requirements.

    This persistent volume claim is associated with the AWS EFS storage class that you have created in step 10b. The value of the storage parameter in the pvc.yaml defines the storage that is available for saving the policy dump.

    In the storageClassName parameter, ensure that you specify the same name for the storage class that you specified in the storage_class.yaml file in step 10a.

    For example, specify efs-sc as the value of the storageClassName parameter.

    f. Run the following command to create the persistent volume claim.

    kubectl apply -f pvc.yaml -n <Namespace>

    For example:

    kubectl apply -f pvc.yaml -n iap-java

    A persistent volume claim is created. In this example, iap-java is the namespace where the Application Protector Java Container will be deployed.

    g. On the Linux instance, create a mount point for the AWS EFS by running the following command.

    mkdir /efs

    This command creates a mount point efs on the file system.

    h. Install the Amazon EFS client using the following command.

    sudo yum install -y amazon-efs-utils

    For more information about installing the EFS client, refer to the section Manually installing the Amazon EFS client in the Amazon Elastic File System User Guide.

    i. Run the following mount command to mount the AWS EFS on the directory created in step 10g.

    sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <file-system-id>.efs.<aws-region>.amazonaws.com:/ /efs

    For example:

    sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-618248e2.efs.<aws-region>.amazonaws.com:/ /efs

    Ensure that you set the value of the <file-system-id> parameter to the value of the volumeHandle parameter, as specified in the pv.yaml file in step 10c.

    For more information about the permissions required for mounting an AWS EFS, refer to the section Working with Users, Groups, and Permissions at the Network File System (NFS) Level in the AWS documentation.

5.2 - Creating a Kubernetes Cluster

This section describes how to create a Kubernetes Cluster on Amazon Elastic Kubernetes Service (EKS) using eksctl, which is a command line tool for creating clusters. The Kubernetes cluster is required for both Dynamic and Static-based deployments.

Note: The steps listed in this section for creating a Kubernetes cluster are for reference use. If you have a Kubernetes cluster or want to create a cluster based on custom requirements, then navigate to step 4 to connect your cluster and the Linux instance. However, you must ensure that your ingress port is enabled on the Network Security group of your VPC.

Important: Ensure that the Kubernetes Metrics Server and Cluster Autoscaler are already deployed.

To create a Kubernetes cluster:

  1. Create a key pair for the EC2 instances that will be launched as part of your Kubernetes cluster.

    For more information on creating the key pair, refer to the section Create a key pair for your Amazon EC2 instance in the Amazon EC2 documentation.

    After the key pair is created, you need to specify the key pair name in the publicKeyName field of the createCluster.yaml file, for creating a Kubernetes cluster.

  2. Log in to the Linux instance and create a file named createCluster.yaml to specify the configurations for creating the Kubernetes cluster.

    The following snippet displays the contents of the createCluster.yaml file.

    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig
    metadata:
      name: <Name of your Kubernetes cluster>
      region: <Region where you want to deploy your Kubernetes cluster>
      version: "<Kubernetes version>"
    vpc:
      id: "<ID of the VPC where you want to deploy the Kubernetes cluster>"
      subnets: #In this section specify the subnet region and subnet id accordingly
        private:
          <Availability zone for the region where you want to deploy your Kubernetes cluster>:
              id: "<Subnet ID>"
          <Availability zone for the region where you want to deploy your Kubernetes cluster>
              id: "<Subnet ID>"
    nodeGroups:
      - name: <Name of your Node Group>
        instanceType: m5.large
        minSize: 1
        maxSize: 3
        tags:
          k8s.io/cluster-autoscaler/enabled: "true"
          k8s.io/cluster-autoscaler/<Name of your Kubernetes cluster>: "owned"
        privateNetworking: true
        securityGroups:
          withShared: true
          withLocal: true
          attachIDs: ['<Security group linked to your VPC>']
        ssh:
          publicKeyName: '<EC2 keypair>'
        iam:
          attachPolicyARNs:
            - "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
          withAddonPolicies:
            autoScaler: true
    

    Important: If you want to copy the contents of the createCluster.yaml file, then ensure that you indent the file as per YAML requirements.

    For more information about the sample configuration file used to create a Kubernetes cluster, refer to the section Create cluster using config file in the eksctl documentation.

    In the ssh/publicKeyName parameter, you must specify the value of the key pair that you have created in step 1.

    In the iam/attachPolicyARNs parameter, you must specify the following policy ARNs:

    • ARN of the AmazonEKS_CNI_Policy policy - This is a default AWS policy that enables the Amazon VPC CNI Plugin to modify the IP address configuration on your EKS nodes.

      For more information about this policy, refer to the AWS documentation.

      You need to sign in to your AWS account to access the AWS documentation for this policy.

    The content snippet displays the reference configuration required to create a Kubernetes cluster using a private VPC. If you want to use a different configuration for creating your Kubernetes cluster, then you need to refer to the section Creating and managing clusters in the eksctl documentation.

    For more information about creating a configuration file to create a Kubernetes cluster, refer to the section Creating and managing clusters in the eksctl documentation.

  3. Run the following command to create a Kubernetes cluster.

    eksctl create cluster -f ./createCluster.yaml

    Important: IAM User 1, who creates the Kubernetes cluster, is automatically assigned the cluster-admin role in Kubernetes.

  1. Run the following command to connect your Linux instance to the Kubernetes cluster.

    aws eks update-kubeconfig --name <Name of Kubernetes cluster>

  2. Validate whether the cluster is up by running the following command.

    kubectl get nodes

    The command lists the Kubernetes nodes available in your cluster.

  3. Deploy the Cluster Autoscaler component to enable the autoscaling of nodes in the EKS cluster.

    This step is required only if the Cluster Autoscaler component is not installed.

    For more information about deploying the Cluster Autoscaler, refer to the section Deploy the Cluster Autoscaler in the Amazon EKS documentation.

  4. Install the Metrics Server to enable the horizontal autoscaling of pods in the Kubernetes cluster.

    This step is required only if the Metric Server is not installed.

    For more information about installing the Metrics Server, refer to the section Horizontal Pod Autoscaler in the Amazon EKS documentation.

    After you have created the Kubernetes cluster, you can deploy the Application Protector Java Container using dynamic or static mode of deployment.

  5. Run following commands to tag the cluster subnets to ensure that the Elastic load balancer can discover them.

    • aws ec2 create-tags --tags Key=kubernetes.io/cluster/<Cluster Name>,Value=shared --resources <Subnet ID>
    • aws ec2 create-tags --tags Key=kubernetes.io/role/internal-elb,Value=1 --resources <Subnet ID>
    • aws ec2 create-tags --tags Key=kubernetes.io/role/elb,Value=1 --resources <Subnet ID>


    Repeat this step for all the cluster subnets.