Isolation and silo for data warehouses in multitenant solutions

How to turn a regular Data Warehouse into multitenant

Just want to note that the magic code does not exist. You can’t just take it and set it up tenant data warehouse bunker. The following aspects should be considered:

• Service Agreement
• Access patterns for reading and writing;
• Compliance with regulations;
• Expenses.

But there are a number of generally accepted data sharing and isolation practices. Consider these cases using the relational database as an example. Amazon aurora.

Partitioning tenant data in shared repositories and instances

Table used by all tenant. Individual data shared and identified by key tenant_id. Authorization in a relational database is implemented at the row level (row-level security) Access to the application is based on the access policy and takes into account the specific tenant.

Pros:

• It’s not expensive.

Minuses:

• Database authorization. This implies several authorization mechanisms within the solution: AWS IAM and database policies;
• For identification tenant will have to develop application logic;
• Without complete isolation it is impossible to enforce the agreement Tier about service;
• Database authorization limits access tracking with AWS CloudTrail. This can only be compensated by adding information from outside. And it would be better to track and troubleshoot.

Isolation of data on shared instance

Rental (tenancy) is still shared at the instance level. But at the same time, data bunkering occurs at the database level. This enables AWS IAM authentication and authorization.

Pros:

• It’s not expensive;
• AWS IAM is fully responsible for authentication and authorization;
• AWS IAM allows you to keep an audit trail on AWS CloudTrail without crutches as separate applications.

Minuses:

• Basic DB instances are shared between tenant, in this regard, the outflow of resources is possible, which does not allow to fully implement the agreement Tier about service.

Database instance isolation for tenant

The diagram shows the implementation tenant databases for instance isolation. Today it is probably the best solution combining safety and reliability. There is also AWS IAM, and audit from AWS CloudTrail, and complete isolation tenant.

Pros:

• AWS IAM provides both authentication and authorization;
• There is a full audit;
• Clear distribution of resources between tenant.

Minuses:

• DB and instance isolation among tenant – it is expensive.

How access of applications to multitenant data is implemented

Ensuring that applications have the correct access to data is more important than storing data in a tenant model that meets business requirements. It is not difficult if you use AWS IAM for access control (see examples above). Applications that provide data access for tenant can also use AWS IAM. This can be seen with an example. Amazon ex.

To provide access to Iam at the level pod in Experfect OpenID Connect (OIDC), along with account annotations Kubernetes. The result will be an exchange Jwt from STS, which will create temporary application access to the necessary cloud resources. With this approach, there is no need to introduce advanced permissions for basic work nodes Amazon ex. Instead, you can only configure permissions. Iam for an account associated with pod. This is done based on the actual permissions of the application, which works as part of pod. As a result, we get full control of application permissions and pod.

{
   ...
   "Statement": [
       {
           "Sid": "Tenant1",
           "Effect": "Allow",
           "Action": "dynamodb:*",
           "Resource": "arn:aws:dynamodb:${region}-${account_id}:table/Tenant1"
       }
   ]
}

eksctl utils associate-iam-oidc-provider 
      --name my-cluster 
      --approve 
      --region ${region}

eksctl create iamserviceaccount 
      --name tenant1-service-account 
      --cluster my-cluster 
      --attach-policy-arn arn:aws:iam::xxxx:policy/aws-dynamodb-tenant1-policy 
      --approve 
      --region ${region}

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
serviceAccountName: tenant1-service-account
 containers:
 - name: tenant1
…