Deploying PrivX to Amazon Web Services

Overview

PrivX can be deployed to Amazon Web Services and configured to use cloud platform services to ensure high availability and scalability.

The overall reference architecture is as follows:

1. PrivX instance is the host the PrivX service will be running on. A suitable starting point for testing is an AWS T2 Medium instance (2 VCPUs, 4GB RAM) running Rocky Linux or RHEL. For production environments, we recommend a m5.large instance with 8 GB RAM as a starting point. You need 2 or more PrivX instances for high availability. More PrivX instances allows greater performance.
2. PrivX VPC will contain the running PrivX instances.
3. AWS Elastic Load Balancer distributes traffic for the PrivX instances for HTTP & HTTPS traffic. Sticky sessions must be enabled.
4. AWS RDS is used for persistence. A suitable starting point is a production PostgreSQL db.r5.large database server with 100 GB storage. For larger production environments, we recommend a DB instance with 32 GB or more memory.
5. AWS EFS is used for audit-trail storage - standard performance with zone redundancy is recommended, size depends on usage.
6. AWS API - if configured to do so, PrivX will index all computing resources from AWS and present them as connectable targets.
7. PrivX Extender is deployed to a VPC and it establishes a secure websocket control connection back to PrivX. It routes traffic from PrivX to target hosts within the VPC.
8. Target VPC is a network containing target hosts which have no publicly accessible addresses.
9. Publicly accessible target hosts can be accessed directly from the PrivX via SSH/RDP in case they have an address the PrivX instance can connect to.

Connections

A. Administrators, end users and API clients will always access PrivX via HTTPS:443. HTTP:80 is required for Windows CRL checks and redirects to HTTPS
B. All PrivX internal communication, including connections from the Application Gateway to application nodes is over HTTPS:443
C. The PrivX Extenders establish secure websocket connections back to PrivX instances - subsequent connections from the Extender to target hosts are done using SSH/RDP
D. PrivX can access target hosts directly via SSH/RDP

PrivX Infrastructure-as-Code (IaC) Deployment via AWS CDK

For fast deployment, PrivX is available as Infrastructure as a Code to be easily installed on your AWS account. Please see https://github.com/SSHcom/privx-on-aws for detailed instructions how to get your PrivX up and running in no time.

Note that PrivX licenses can be activated only a limited number of times. In case you have already installed PrivX and would like to redeploy IaC installation, before you do so you must first deactivate the license in your current PrivX.

To deactivate a PrivX license, go to the Administration→License page. Next to Status, click , then click Deactivate.

Manual Deployment

1. Configure AWS RDS database for PrivX
2. Create an EC2 autoscaling group for PrivX EC2 instances
3. Create an AWS Elastic Load Balancer for PrivX
4. Create an EC2 instance for PrivX (Amazon Linux, RHEL)
5. Install PrivX, configure PrivX to connect to RDS
6. Create AWS EFS for PrivX (NFS accessible from PrivX EC2 instance), mount boot-persistent privx user owned /var/privx/audit
7. Attach PrivX EC2 instance to the ELB and ensure that it works
8. Take a snapshot of the PrivX EC2 instance and configure it to the autoscaling group. Set minimum number of running instances to the autoscaling group.
9. Terminate initial EC2 instance and observe the autoscaling group starting a new instance from the snapshot
10. Configure ELB to inform autoscaling group of an instance malfunction (ELB health check needs to poll path /monitor-service/api/v1/instance/status). See High-Availability Deployment for more info.

For production environments, it is recommended to use the CDK tooling (See PrivX infrastructure as code via AWS CDK) or self-made CloudFormation or similar template to set up the environment.

Upgrade

1. Detach instances from the ELB
2. Set autoscaling group instance count to 1
3. Transfer PrivX upgrade package to the remaining host or use PrivX repository
4. Upgrade host, run yum update PrivX
5. Attach the instance to ELB, verify that PrivX works
6. Take a snapshot of the instance, attach the snapshot to autoscaling group
7. PrivX is updated

For production HA deployments, see High-Availability Upgrade.

Backup & Restore

PrivX automatically creates full backups (certificates and configuration files) and stores them to /var/backups/privx. Ideally, this directory would be mounted to AWS EFS.

1. Transfer the backup directory from /var/backups/privx/hostname_yyyy-mm-dd-hhmm_privx-version to a new PrivX instance
2. Install PrivX (do not run postinstall.sh after)
3. Set environment variable, run export SKIP_POSTINSTALL=1
4. yum install PrivX
5. Run /opt/privx/scripts/restore.sh /path/to/backup/directory/from/node/one/hostname_yyyy-mm-dd-hhmm_privx-version
6. Ensure that the PrivX service is functional
7. Take a snapshot of the instance and attach the snapshots to autoscaling group

In HA environments, the PrivX Database must be backed up separately.

Disclaimers

This document includes instructions regarding third-party products by Amazon. This blueprint is provided for general guidance only.

The architecture in this blueprint was verified against the Amazon Web Services products current in April 2019. These instructions will need to be adapted when using other versions of Amazon Web Services products.

SSH Communications Security Corporation does not make any warranties as to the accuracy, reliability, or usefulness of these instructions, or guarantee that the content related to third-party products is up to date.

SSH Communications Security Corporation does not provide any warranties regarding third-party products, such as Amazon Web Services, nor provide any support or other services for third-party products.

For instructions about setting up and operating Amazon Web Services products, we always recommend that you consult the official Amazon Web Services documentation intended for the specific version(s) of Amazon Web Services products in your use, and/or directly contact Amazon Web Services representatives or support.