Self Service Password Reset provides two deployment on Amazon EKS with EC2 instances. You must choose the options that work best for your environment and incoming traffic load.
Self Service Password Reset container comes with the following deployment options:
Single replica: Deploying a single replica of Self Service Password Reset on EC2 instance, with a single dedicated EFS for storage. This is an easy deployment setup and deployment option managed with one EFS file. Since there is only one EFS file, the data is consistent and inherited.
Example: Let us consider a small-scale Insurance company xyz.Ltd has an application where they allow their customers to view their policies, submit claims, and view the status of the submitted claims. This company has very limited customers. Since they have a limited customer base and a low volume of incoming traffic, they can deploy a single replica to maintain and manage the data.
Multiple replica: Deploying a multiple replica of Self Service Password Reset on EC2 instance, each with its own dedicated EFS for file storage. If your organization has high traffic volumes and requires the application to scale dynamically, maintain high availability during failures, and effectively serve geographically dispersed users, then deploy multiple replica.
In this deployment setup, each replica has its own independent EFS file storage. As a result, data is not automatically synchronized across replicas. Consequently, if a user saves data to the EFS file associated with one replica and later accesses a different replica, there is no assurance that the data will be available because of separate EFS file.
To address this issue, you must choose one of the following approaches based on your requirements and the trade-offs of each option:
Synchronize data: To ensure data consistency across replicas, you must manually synchronize the EFS files. To achieve this, you must implement an effective synchronization mechanism that ensures the changes from one replica are reflected in all other replicas.
Example: The XYZ Ltd. organization uses a tracker application shared by multiple departments such as Engineering, Marketing, and HR. If the Engineering team makes changes to the tracker through one replica, it is crucial that the HR team can view and update these changes through a different replica. This ensures that updates made by any department are synchronized and are visible across all other departments.
Independent data: You can manage the data independently within each replica without synchronization. This option simplifies the deployment, makes data management easier, and eliminates the synchronization overhead. However, this risks data inconsistency if a user switches between replicas, as the data is not shared across replicas. To address this, you must implement additional strategies to ensure that the same user consistently accesses the same replica.
Example: XYZ Ltd. has a Tropy application for their users to update their profiles. The organization does not synchronize data across multiple replicas. A user Maria initially accessed the Tropy application through Replica 1 and made some changes to her profile. After 45 minutes, when she logs in again, she is required to access the same data.
To ensure Maria always reaches the same replica where her data is stored, XYZ Ltd. uses a session affinity mechanism. This setup guarantees that when Maria accesses the application, she is directed to Replica 1 each time, allowing her to store and retrieve her data from the EFS file associated with Replica1.
A Kubernetes cluster (v1.19 or later) with Role-Based Access Control enabled.
Created an account on Amazon Elastic Kubernetes Service (Amazon EKS).
Created an Amazon EKS cluster.
For more information about how to create an Amazon EKS cluster, refer the Get started with Amazon EKS section in the Amazon EKS User Guide.
The Kubernetes cluster should contain one Master node and at least one Worker node.
The kubectl command-line tool is installed on your machine and configured it to work with Amazon EKS.
For more information about installing and configuring kubectl, see the Set up kubectl and eksctl and Connect kubectl to an EKS cluster by creating a kubeconfig file sections in the Amazon EKS User Guide.
Verify that Route 53 effectively handles DNS resolution for the resources deployed by the SSPR Helm chart through necessary configurations and checks. For details, see the AmazonRoute 53 Developer Guide.
Create SSL/TLS certificate in ACM and associate them with the ALB in your EKS cluster to ensure secure communication between clients and the ALB. For more information, see the AWS Certificate Manager User Guide.
Create a NAT Gateway in AWS to allow instances in your private subnets to access the Internet. For more information, see the Work with NAT gateways section in the Amazon Virtual Private Cloud User Guide.
Create a shared EFS file system within your AWS account. For more information, see the Amazon Elastic File System User Guide.
Download the Self Service Password Reset Docker image (sspr-docker-image.x.x.x.x.tar.gz) from OpenText Downloads.
For example, sspr-docker-image.4.8.0.0.tar.gz
Create one or more ECR repositories and upload the downloaded Self Service Password Reset Docker container images. For more information, see the Amazon ECR User Guide.
Helm 3.x is installed.
Install and configure AWS Load Balancer Controller. For more information, see the Install the AWS Load Balancer Controller using Helm section in the Amazon EKS User Guide.
This section lists the security best practices for Self Service Password Rest containers on Amazon EKS with EC2 instances. It secures the application from unauthorized access, vulnerabilities, and threats.
This section covers the following best practices:
Security groups function as a virtual firewall for your EC2 instances to manage incoming and outgoing traffic. Security groups can be configured to allow or restrict access based on IP addresses, ports, and protocols.
Ensure you do not open every port in the security group when configuring them for SSPR deployment.
Configure only the following ports in order for SSPR to function:
Table 7-3
|
Components |
Ports |
|---|---|
|
HTTPS |
443 8443 9443 |
|
LDAP |
636 |
|
Network File System (NFS) |
2049 |
|
Database |
PostgreSQL: 5432 Microsoft SQL Server: 1433 Oracle: 1521 |
You must clear the sensitive information, such as password from values.yaml after the deployment is complete.When inputs (password) are sent by using the --set command, it is visible when you run the helm get values <release name> command.
Auto-scaling the Self Service Password Reset containers is not supported.