Skip to content

Deploy Satori CH on Azure

The following section describes the main components of the Satori Customer Hosted (CH) Platform and how to deploy the solution on Azure.

Introduction to Satori CH for Azure

The Satori CH platform consists of two main components:

  • The Satori Cyber Application Application
  • The Satori CH Data Access Controller (DAC) - a Kubernetes application that is either consumed as a service or deployed on an Azure Kubernetes Service (AKS) inside the customer VNet.

Deploying Satori Customer Hosted (CH)

Deploy the Satori CH DAC in the same Azure region as the data stores the DAC is meant to protect.

For example, customers using SQL Server on Azure East US 2 should deploy the Satori CH DAC in a VNet in the same region.

Screenshot

High Level Satori Deployment on Azure Architecture

The Satori CH DAC is accessed by the user, by using a dedicated hostname for each data store that the Satori CH DAC protects.

For example, to access a SQL Server database hosted in Azure East US at acme1.database.windows.net, data consumers will instead connect to acme1.eastus.z.p1.satoricyber.net..

The new hostname resolves to an internal-facing load-balancer that routes traffic to the Satori DAC inside the AKS cluster.

Screenshot

Satori CH DAC Network Configuration

The Satori CH DAC requires the following network path configurations:

  1. User Connection to the Satori DAC - Users connect to data stores via the Satori DAC, therefore a network path from users to the Satori DAC is required.
  2. Satori DAC Connection to the Data Store - the Satori DAC receives queries from users and then sends them to the data stores it protects, so a network path from the Satori DAC to the data stores is required. Typically, this is established by deploying the Satori DAC in the same VPC as the data stores it protects and ensuring that the AWS security groups allow access from the Satori DAC to the data stores.
  3. Satori DAC Connection to the Internet - the Satori DAC requires connectivity to the internet for the following purposes:
  4. Set the HTTPS port 443 to google.com, googleapis.com and gcr.io - Satori uses several services from the Google cloud platform (GCP) as well as a GIT repository that contains the Satori DAC's configuration files, a secret manager for secure storage of secrets and a messaging service to publish data access metadata that is shared with the management console. The full list of fields that are sent is available here: Metadata Shared by Data Access Controllers with the Management Console.
  5. Set the HTTPS to port 443 to cortex.satoricyber.net - (the product telemetry metrics are uploaded here).

Private or Public Facing Data Access Controller

You can choose to deploy a private, VPC-only facing Satori CH DAC, or a public, internet-facing Satori CH DAC.

Azure Internal Load Balancer

For customers who want to define an internal load balancer and require the load balancer to be placed in a pre-defined subnet, open a support ticket with the Satori support team to update the deployment package with the name of the subnet.

Please note that in certain cases, the cluster's service principal might not have the required permissions to create a load balancer in the specified subnet. To grant it the necessary permissions, perform the follow steps prior to deployment:

az aks show --resource-group <RG_NAME> --name <CLUSTER_NAME> --query servicePrincipalProfile.clientId
az ad sp show --id <CLUSTER_SP_CLIENT_ID> --query objectId
az role assignment create --role "Contributor" --resource-group <RG_NAME> --assignee-object-id <CLUSTER_SP_OBJECT_ID>

For more information, see the Azure documentation.

Load-balancer stuck in "pending" state - Customers that use the Azure CNI networking option with the "System-assigned managed identity" authentication mode may encounter this issue.

To overcome this, please make sure the cluster is created with authentication mode "Service principal" For more information see the Internal Load Balancer using Azure Stuck on Pending

Screenshot

Satori CH Deployment Prerequisites

The following section details the Satori CH deployment prerequisites for configuring Satori CH on Azure.

Satori CH Hostname DNS

Satori CH generates a unique hostname for each data store that it protects in a DNS zone that is unique for each Satori CH DAC. For private facing Satori CH DACs, customers should host the DNS zone on a DNS service the same as the Azure DNS.

For public facing Satori CH 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.eastus.z.p1.satoricyber.net.
*.acme1.eastus.z.p1.satoricyber.net.   A   20.14.113.2.

Kubernetes Cluster Requirements

Satori CH is designed to run on the Azure Kubernetes Service (AKS) and requires a cluster with the minimum Kubernetes version v1.18.

Virtual Machine Configurations

A minimum of 2 DS2 v2 VMs are required by the Satori CH 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.

Cluster Deployment

Satori recommends deploying 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.

Outbound Network Access

  • HTTPS on port 443 is set to google.com, googleapis.com and gcr.io - Satori uses several services from GCP including a Git repository that holds the Satori DAC 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 Metadata Shared by Data Access Controllers with the Management Console. - HTTPS on port 443 to cortex.satoricyber.net - this is where product telemetry (metrics) are uploaded to.

Screenshot

Deployment Client

Satori provides a python3 deployment script that uses Helm 3 to deploy the Satori CH DAC on the Kubernetes cluster.

Perform the following steps to extract and deploy the Satori DAC upgrade

  1. Login to the Satori CH Management Console at Satori Cyber Application.
  2. Go to Settings, Data Access Controllers and select the target DAC. Contact Support if you need to create a new DAC.
  3. Select the desired deployment package and click Download.
  4. Extract the deployment package and open a terminal window to the directory where the deployment package was extracted.
  5. The package contains a helm chart that is installed using a helm command.
helm upgrade --install --create-namespace -n satori-runtime  --wait --values version-values.yaml --values customer-values.yaml --values customer-override.yaml runtime satori-runtime

Upgrading Satori CH DAC

To upgrade your Satori CH DAC and enjoy the latest features, fixes and security improvements go to the Upgrading Satori section.