How exactly to implement SaaS tenant isolation with AWS and ABAC IAM
Multi-tenant applications should be architected so the sources of each tenant are isolated and can’t be accessed by other tenants in the machine. AWS Identity and Access Management (IAM) is usually a important element in achieving this goal. Among the challenges with using IAM, however, is that the quantity and complexity of IAM policies you will need to aid your tenants can grow rapidly and impact the scale and manageability of one’s isolation model. The attribute-based access control (ABAC) mechanism of IAM provides developers with ways to address this challenge.
<p>In this website post, we describe and offer detailed examples of ways to use ABAC in IAM to implement tenant isolation in a multi-tenant environment.</p>
Choose an IAM isolation method
IAM can help you implement tenant isolation and scope down permissions in a manner that is integrated with other AWS services. By counting on IAM, it is possible to create strong isolation foundations in one’s body, and reduce the threat of developers introducing code leading to a violation of tenant boundaries unintentionally. IAM has an AWS native, non-invasive way to achieve isolation for all those cases where IAM supports policies that align together with your overall isolation model.
There are many methods in IAM which you can use for isolating tenants and restricting usage of resources. Deciding on the best method for the application depends upon several parameters. The amount of tenants and the amount of role definitions are two important dimensions that you ought to consider.
Most applications require multiple role definitions for different user functions. A job definition refers to a minor group of privileges that users or programmatic components need to carry out their job. For instance, business users and data analysts could have different group of permissions to allow& typically;nbsp;minimum necessary usage of resources they use.
In software-as-a-service (SaaS) applications, along with functional boundaries, you can find boundaries between tenant resources also. As a result, the complete group of role definitions exists for every individual tenant. In highly dynamic environments (e.g., collaboration scenarios with cross-tenant access), new role definitions could be added ad-hoc. In that full case, the amount of role definitions and their complexity can grow because the system evolves significantly.
You can find three main tenant isolation methods in IAM. Let’s briefly review them before concentrating on the ABAC in the next sections.
RBAC – Each tenant includes a dedicated IAM role or static group of IAM roles that it uses for usage of tenant resources. The amount of IAM roles in RBAC equals to the amount of role definitions multiplied by the amount of tenants. RBAC is effective when you have a small amount of tenants and relatively static policies. You might find it difficult to control multiple IAM roles because the amount of tenants and the complexity of the attached policies grows.
Dynamically generated IAM policies – This technique dynamically generates an IAM policy for a tenant in accordance with user identity. Choose this technique in highly dynamic environments with changing or frequently added role definitions (e.g., tenant collaboration scenario). You may even choose dynamically generated policies when you have a preference for generating and managing IAM policies through the use of your code instead of counting on built-in IAM service features. You’ll find more details concerning this method in your blog post Isolating SaaS Tenants with Dynamically Generated IAM Policies.
ABAC – This technique is suitable for an array of SaaS applications, unless your use case requires support for changed or added role definitions frequently, which are simpler to manage with dynamically generated IAM policies. Unlike Dynamically generated IAM policies, where you manage and apply policies by way of a self-managed mechanism, ABAC enables you to rely more on IAM directly.
ABAC for tenant isolation
ABAC is attained by using parameters (attributes) to regulate tenant usage of resources. Using ABAC for tenant isolation results in temporary usage of resources, that is restricted based on the caller’s attributes and identity.
Among the key benefits of the ABAC model is that it scales to a variety of tenants with an individual role. That is attained by using tags (like the tenant ID) in IAM polices and a temporary session specifically made for accessing tenant data. The session encapsulates the attributes of the requesting entity (for instance, a tenant user). At policy evaluation time, IAM replaces these tags with session attributes.
Another element of ABAC may be the assignation of attributes to tenant resources through the use of special naming conventions or resource tags. The usage of a resource is granted when session and resource attributes match (for instance, a session with the TenantID: yellow attribute can access a resource that’s tagged as TenantID: yellow).
To find out more about ABAC in IAM, see What’s ABAC for AWS?
ABAC in an average SaaS architecture
To show ways to use ABAC in IAM for tenant isolation, we will walk you via an example of an average microservices-based application. More specifically, we shall concentrate on two microservices that implement a shipment tracking flow in a multi-tenant ecommerce application.
Our sample tenant, Yellow, which includes many users in lots of roles, has exclusive usage of shipment data that belongs to the particular tenant. To do this, all microservices in the decision chain operate in a restricted context that prevents cross-tenant access.
Let’s have a closer go through the sequence of events and discuss the implementation at length.
A shipment tracking request is set up by an authenticated Tenant Yellow user. The authentication process is overlooked of the scope of the discussion with regard to brevity. An individual identity expressed in the JSON Web Token (JWT) includes custom claims, among which really is a TenantID. In this example, TenantID equals yellow.
The JWT is delivered from the user’s browser in the HTTP header of the Get Shipment request to the shipment service. The shipment service then authenticates the request and collects the mandatory parameters so you can get the shipment estimated time of arrival (ETA). A GetShippingETA is manufactured by the shipment service request utilizing the parameters to the tracking service combined with the JWT.
The tracking service manages shipment tracking data in a data repository. The repository stores data for several of the tenants, but each shipment record comes with an attached TenantID resource tag, for example yellow, as inside our example.
An IAM role mounted on the tracking service, called TrackingServiceRole in this example, determines the AWS resources that the microservice can access and what it could perform.
Remember that TrackingServiceRole itself doesn’t have permissions to gain access to tracking data in the info store. To get usage of tracking records, the tracking service assumes another role called TrackingAccessRole. This role remains valid for a restricted time frame, until credentials representing this temporary session expire.
To comprehend how this ongoing works, we need to discuss the trust relationship between < first;strong>TrackingAccessRole and TrackingServiceRole. The next trust policy lists TrackingServiceRole as a reliable entity.