Validating the Installation

After the deployment procedure is complete, you should validate the deployment to ensure that everything is working according to your needs. The deployment may take approximately 3-4 minutes to complete.

To validate if the Certified Container Software deployment using Helm charts is successful, invoke the following commands to verify the status (STATUS is DEPLOYED) for a Helm chart with release, <my-release> and namespace, my-namespace.
  • Check the Helm chart release status by invoking the following command and verify that the STATUS is DEPLOYED:
    helm status cm-release -n my-namespace
    helm status engine-release -n my-namespace
    helm status ps-release -n my-namespace
    
  • Wait for the pod to be ready. To verify the pods status (READY) use the dashboard or through the command line interface by invoking the following command:
    kubectl get pods -l release=cm-release -n my-namespace -o wide
    kubectl get pods -l release=engine-release -n my-namespace -o wide
    kubectl get pods -l release=ps-release -n my-namespace -o wide
    
  • To view the service and ports exposed to enable communication in a pod invoke the following command:
    kubectl get svc -l release=cm-release -n my-namespace -o wide
    kubectl get svc -l release=engine-release -n my-namespace -o wide
    kubectl get svc -l release=ps-release -n my-namespace -o wide
    

    The screen output displays the external IP and exposed ports under EXTERNAL-IP and PORT(S) column respectively. If external Load Balancer is not present, refer Master node IP as external IP.

Exposed Services for Configuration Manager

If required, this chart can create a service of ClusterIP for communication within the cluster. This type can be changed while installing chart using service.type key defined in values.yaml. There are two ports where IBM Sterling Secure Proxy Configuration Manager processes run. Web server port (8443) and cm port (62366) whose values can be updated during chart installation using service.jetty.servicePort or service.cm.servicePort. IBM Sterling Secure Proxy Configuration Manager can be accessed using Load Balancer external IP or mapped Jetty Port. If Load Balancer is not present, then refer to Master node IP for communication.
Note: NodePort service type is not recommended. It exposes additional security concerns and is hard to manage from both an application and networking infrastructure perspective.

Exposed Services for Engine

If required, this chart can create a service of ClusterIP for communication within the cluster. This type can be changed while installing chart using service.type key defined in values.yaml. There are two ports where IBM Sterling Secure Proxy Engine processes run, Engine port (63366) and More Secure PS port whose values can be updated during chart installation using service.engine.servicePort or service.moreSecurePS.servicePort. IBM Sterling Secure Proxy Engine can be accessed using Load Balancer external IP or mapped Jetty Port. If Load Balancer is not present, then refer to Master node IP for communication.
Note: NodePort service type is not recommended. It exposes additional security concerns and is hard to manage from both an application and networking infrastructure perspective.

Exposed Services for Perimeter Server

If required, this chart can create a service of ClusterIP for communication within the cluster. This type can be changed while installing chart using service.type key defined in values.yaml. There is a port where IBM Sterling Secure Proxy Perimeter Server processes run, PS port whose value can be updated during chart installation using service.psLessSecure.servicePort. IBM Sterling Secure Proxy Perimeter Server can be accessed using Load Balancer external IP or mapped Jetty Port. If Load Balancer is not present, then refer to Master node IP for communication.
Note: NodePort service type is not recommended. It exposes additional security concerns and is hard to manage from both an application and networking infrastructure perspective.

DIME and DARE Security Considerations

This topic provides security recommendations for setting up Data In Motion Encryption (DIME) and Data At Rest Encryption (DARE). It is intended to help you create a secure implementation of the application.

  1. All sensitive application data at rest is stored in binary format so user cannot decrypt it. This chart does not support encryption of user data at rest by default. Administrator can configure storage encryption to encrypt all data at rest.
  2. Data in motion is encrypted using transport layer security (TLS 1.2). For more information click here.