# Security Practices for Multi-Tenant SaaS Applications using Amazon EKS
<a name="security-practices-multi-tenant-saas-applications-eks"></a>

Publication date: **June 4, 2021** ([Document history](document-revisions.md))

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)](https://aws.amazon.com/eks/) clusters.

This document was adapted from the [https://aws.github.io/aws-eks-best-practices/](https://aws.github.io/aws-eks-best-practices/). The *Best Practices Guide* is updated frequently. AWS recommends checking for updates periodically, because [Amazon EKS](https://aws.amazon.com/eks/) and [Kubernetes](https://kubernetes.io/) are rapidly evolving. AWS also recommends subscribing to the [AWS Containers Blog](https://aws.amazon.com/blogs/containers/) to receive the latest updates on AWS container services. 

## Overview
<a name="overview"></a>

 [https://aws.amazon.com/eks/](https://aws.amazon.com/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.