Introducing Satori for ECS

From the very beginning, Satori’s vision has been to be a universal data security platform that can be deployed across all of our customers’ data stores, no matter the tech stack, and can support different deployment options. 

We’ve been fortunate to provide our customers with self-service data access, automated compliance and masking, and posture management capabilities through a very quick deployment process via Kubernetes. Today, we’re happy to announce that Satori is now available on ECS, opening up our platform to reach a wider audience. 

When we first built Satori’s Data Access Controller (DAC), we needed an orchestration platform that would enable us to support all the major cloud platforms. We chose Kubernetes due to its power, portability, and extensibility, and over time have expanded to support various on-premises Kubernetes flavors. But while Kubernetes is widely recognized as the industry leader, we understand that not all data teams have the capacity to adopt it. 

For teams with smaller deployments, limited resources, or those that are deeply embedded into the AWS ecosystem, Amazon’s Elastic Container Service (ECS) is a solid option. ECS is a fully managed container orchestration service, which supports scaling and tight integration with other AWS services. What it lacks in the functionality that Kubernetes offers, ECS makes up for in its moderate learning curve and simplicity. Now, data teams deploying on ECS can benefit from Satori’s data security and access management capabilities.

This section discusses the design considerations we made in our implementation of Satori for ECS. After making the decision to support ECS, the first thing we did was map out the gaps between the native features of ECS and Kubernetes. For the tools and features we had in place that aren’t native to ECS, we needed to find equivalents to fill these gaps. Below we’ll discuss some of the design decisions we made, and challenges we met during the process.

Our current DAC installation package is based on helm, the Kubernetes package manager. For the ECS implementation, we selected Hashicorp’s Terraform, a complete and extensible solution that we could integrate with the Satori Terraform provider.

The native metrics collection facility for ECS is Cloudwatch, while for Kubernetes we have a Prometheus instance deployed on the cluster, reporting metrics back to a central metrics aggregator. Since we have a centralized metrics collection system, we opted for Prometheus as our metrics collection monitoring system. We deployed our own Prometheus instance as a separate task with a sidecar for automatic ECS discovery, based on the prometheus-ecs-discovery project.

The Kubernetes cluster makes use of a Fluentbit daemonset, which is used for exporting the logs into a global aggregator, in this case Elasticsearch. A different approach was needed for an ECS cluster since there is no out-of-the-box method for exporting logs to an arbitrary target. While AWS does provide a method of extracting logs via Fluentbit image, setting this up was not trivial. We decided instead to go with the native Cloudwatch log collection service.

While Kubernetes provides options around secret lifecycle management (external secrets), options in ECS are limited to the AWS Secrets Manager integration. Another issue that came up is that Kubernetes’ ability to mount secrets as files doesn’t exist on ECS. In order to overcome the secrets mounting issue, we added a container init script that generates a secret file based on the environment variable secret. Secrets are refreshed when a pod restarts.

Teams can now deploy Satori on ECS as a single container DAC with support for auto scaling. The cluster integrates with the AWS Redis service (ElastiCache) to reduce cluster footprint. Check out our docs to learn how to deploy Satori on ECS in your virtual private cloud (VPC).

High-level illustration of the Satori architecture when deployed in a customer’s virtual private cloud (VPC) on AWS.

Satori is continuously working to improve the deployment experience over ECS. To ensure the ECS deployment is fully on par with its Kubernetes counterpart, we’ll be implementing dynamic secrets rotation in AWS Secrets Manager, and developing an integration to route and aggregate logs in Elasticsearch. We’re excited to grow and expand the capabilities of Satori’s deployment option over ECS, helping more and more teams achieve fast, scalable, self-service data access without compromising security and compliance.

Relevant links:

• Learn more about Satori’s Data Security Platform
• Read about how Satori secures your data on AWS Athena and AWS Redshift
• Find Satori on the AWS Marketplace