Security Practices for Multi-Tenant SaaS Applications using Amazon EKS - Security Practices for Multi-Tenant SaaS Applications using Amazon EKS
Overview

Security Practices for Multi-Tenant SaaS Applications using Amazon EKS

Publication date: June 4, 2021 (Document history)

This guide shows you how to securely manage and operate multi-tenant software-as-a-service (SaaS) applications on Amazon Elastic Kubernetes Service (Amazon EKS) clusters.

This document was adapted from the Amazon EKS Best Practices Guide. The Best Practices Guide is updated frequently. AWS recommends checking for updates periodically, because Amazon EKS and Kubernetes are rapidly evolving. AWS also recommends subscribing to the AWS Containers Blog to receive the latest updates on AWS container services.

Overview

Amazon Elastic Kubernetes Service (Amazon EKS) is frequently used by customers who are building software-as-a-service (SaaS) solutions on AWS. How tenant data and applications are isolated in these SaaS solutions can vary. Some SaaS providers rely on a siloed tenancy model where each tenant has its own resources. Others rely on a pooled tenancy model where resources are shared by tenants.

The following provides a more detailed overview of how these two models are realized on Amazon EKS:

  • The Pool Model describes an environment where the EKS resources are shared by tenants with added measures to ensure that any one tenant cannot access the resources of another tenant. Many customers want to run workloads using shared hosts and a common control plane. This approach typically simplifies the operational footprint of a SaaS application and improves the agility, innovation, and cost model of a SaaS environment.

  • The Silo Model represents a model where each tenant has dedicated EKS resources. This model is often a good fit for tenants that may demand a more absolute isolation boundary. This may be for a variety of reasons (security, noisy neighbors, and so on). There are multiple constructs available in EKS that can be used to realize the Silo model. The resources accessed from a silo could be deployed in a silo or pool model.

These choices are not exclusive. Some SaaS providers may support both options depending on the tiers or services that are part of their application.

For both of these models, it's important ensure that tenants are unable to:

  • Read or write any control-plane information unrelated to the tenant.

  • Access any resources not belonging to the tenant.

  • Obtain credentials not belonging to the tenant.

  • Impersonate other tenants.

  • Escape the confines of the tenant’s allocated compute, memory, or other resources.