Satori AWS Deployment Guide
The Satori secure data access platform consists of two main components:
- The Satori management console (https://app.satoricyber.com) - a SaaS application hosted on GCP.
- The Satori data access controller (DAC) - a Kubernetes application that is either consumed as a service or deployed on an AWS Elastic Kubernetes Service (EKS) inside the customer VPC.
Customers deploy a DAC in the same public cloud region as the data stores the DAC protects. For example, customers using Redshift on AWS us-east-2 should deploy a DAC in a VPC on AWS us-east-2.
The DAC is accessed by users using a dedicated hostname for each data store the DAC protects. For example, to access the Redshift cluster at
cluster1.cxjks.us-east-2.redshift.amazonaws.com, data consumers will instead connect to
cluster1.acme1.us-east-2.a.p1.satoricyber.net. The new hostname resolves to an internal-facing load-balancer that routes traffic to the Satori DAC inside the EKS cluster.
Private or Public Facing Data Access Controller
Customers can choose to deploy a private, VPC-facing DAC or a public, internet-facing DAC. The choice of deployment dictates which load balancer and DNS setup the DAC will use.
DNS for the Satori Hostnames
Satori generates a unique hostname for each data store that it protects, in a DNS zone that is unique for each DAC. For private facing DACs, customers should host the DNS zone on a DNS service like Amazon Route 53. For public facing DACs, Satori provides the option to use Google DNS, at no extra cost.
The DNS zone would have a root hostname pointing to the load balancer, and a wildcard entry for the data store specific hostnames. For example:
$ORIGIN acme1.us-east-2.a.p1.satoricyber.net. *.acme1.us-east-2.a.p1.satoricyber.net. CNAME a174b67fb0e35449982d4280ee24917e-100247109.us-east-2.elb.amazonaws.com.
Satori is designed to run on Elastic Kubernetes Service (EKS) and requires a cluster with Kubernetes version v1.18.
A minimum of 2 m5.large EC2 VMs are required by the DAC, with each VM processing up to 20MB/s of data traffic. For most deployments that is sufficient, however, additional VMs should be added if higher traffic loads are expected. The DAC is horizontally scalable and will automatically request more resources if it needs to.
It is recommended to deploy the cluster on more than one availability zone. For example, when deploying a cluster with two VMs on two availability zones, one VM will be created in each zone.
For an example on how to set up an EKS cluster for Satori, see our github repo.
Outbound Network Access
- HTTPS on port 443 to
gcr.io- Satori uses several services from GCP including a Git repository that holds the DAC's configuration files, a secret manager for secure storage of secrets and a messaging service to publish data access metadata which is shared with the management console. The full list of fields that are being sent is available here.
- HTTPS on port 443 to
cortex.satoricyber.net- this is where product telemetry (metrics) are uploaded to.
Satori provides a python3 deployment script that uses Helm 3 to deploy the DAC to the Kubernetes cluster.
Step by Step Instructions
- Login to the Satori management console at (https://app.satoricyber.com).
- Go to Settings, Data Access Controllers and select the DAC to deploy to. Please contact Support if a new DAC needs to be created.
- Select the desired deployment package and click Download.
- Extract the deployment package and open a terminal window to the directory where the deployment package was extracted.
python3 satori.pyto start the deployment process.
To upgrade the DAC, repeat steps (2)-(5).