Skip to content

Satori Azure Deployment Guide

The following section describes the main compontents that comprise the Satori Data Access Platform and how to deploy the solution on Azure.

Introduction to Satori for Azure

The Satori secure data access platform consists of two main components:

  • The Satori management console Satori Cyber Application - 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 Azure Kubernetes Service (AKS) inside the customer VNet.

Customers deploy a DAC in the same Azure region as the data stores the DAC protects. For example, customers using SQL Server on Azure East US 2 should deploy a DAC in a VNet in the same region.

Screenshot

High Level Satori Deployment on Azure Architecture

The DAC is accessed by users using a dedicated hostname for each data store the 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.

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.

Azure Internal Load Balancer

For customers who choose the internal load balancer, and require the load balancer to be placed in a pre-defined subnet, please open a support ticket with Satori support team to update the deployment package with the name of the subnet. Please note that in some cases, the cluster's service principal might not have permissions to create a load balancer in the specified subnet. To grant it permissions, follow these 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.

Customers who are using the Azure CNI networking option with the "System-assigned managed identity" authentication mode might encounter an issue of the load-balancer stuck in "pending" state. To overcome this, please make sure the cluster is created with authentication mode "Service principal" (see more details here: https://docs.microsoft.com/en-us/answers/questions/271470/internal-load-balancer-using-azure-cni-stuck-on-pe.html)

Satori Deployment Prerequisites

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

Satori Hostname DNS

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 Azure DNS. 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.eastus.z.p1.satoricyber.net.
*.acme1.eastus.z.p1.satoricyber.net.   A   20.14.113.2.

Kubernetes Cluster

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

A minimum of 2 DS2 v2 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.

Outbound Network Access

  • HTTPS on port 443 to google.com, googleapis.com and 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 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.

Deployment Client

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

Step by Step Instructions

  1. Login to the Satori management console at Satori Cyber Application.
  2. Go to Settings, Data Access Controllers and select the DAC to deploy to. Please contact Support if a new DAC needs to be created.
  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. Run python3 satori.py to start the deployment process.

To upgrade the DAC, repeat steps (2)-(5).