In Deployment of software deployment, multi tenant systems make sense, to separate teams or different customers, with different use cases. Ideally a tenant is separated like it is running in its own system and has all configuration options and network security options individually configured.
On the other hand complexity should still be manageable, to make sure errors can be analyzed quickly and new personnel is onboarded quickly.
In this post I want to write down some concepts and ideas, as well as best practices. First looking at common concepts and ideas.
Generally, default patterns are useful for onboarding new features. Of course each goal/software solution is unique and needs to be planned individually.
I am thankful for any comment or discussion. This is my current point of view, which might change in the future.
Databases
Most environments have a persistence in some sort of database. These could be a document, graph, relational or other concept.
Following separations are possible:
- All data in one scheme: tenant connection determined via references to the tenant. Cross connection is easy.
- Own scheme for each tenant: every tenant access needs separate authentication.
Additionally there can be a management scheme, containing general information and references to the tenants, this can be a general database scheme or can be defined in the configuration.
Although the complexity is higher I personally would mostly choose the multi scheme approach. The higher complexity to reach other tenants data from within the context is much harder. In this approach persisted data can even be physically separated.
Authentication
Authorization is one of the core security gateways. Generally standardized and tested approaches should be used. Current state of the art would be OAuth2/OIDC, which is an open standard, integrated in lot of frameworks and security and best practices are available broadly.
Here are again two concepts
- One identity provider
- Separate identity providers
Identity Provider (IDP) could also be a REALM or App, depending on the wording.
Technology wise it is easiest to have one provider. within the source code only one IAM needs to be checked, and changes within the token information/structure needs to be done for all Identity Providers. In case of one identity provider the tenant needs to be in the Token, to verify resource access.
On the other hand it is much harder to get a valid access token with escalated privileges from another identity provider. In this case for example when logging in the login page forwards to the correct IDP or the reference to the correct IDP is in the URL/FQDN.
Services
Looking at resource costs, the goal is to allocate as few resources as possible. So most of the times it makes sense to share the service instances and check the tenant within.
For safer environments it can make sense to deploy a separate service, which only gets access to the data of the connected tenant. In this case only the services dealing with sensitive data should be scaled like this. Data then can be forwarded to the right service by the gateway. It makes sense when all services between the user call and the service handling the information are separate services, to ensure no access from other tenants.
Configuration
The challenge with configuration is, that it is often loaded with service start up. One possibility is to not use the native configuration logic, and load all configuration from the tenant database/data when accessed. Another possibility is to have a configuration map loaded, which can
Some service wide settings, like the port, TLS headers or such parameters can only be configured per service, in this case a multi service approach should be verified, like described before.
Logging
Each tenant specific logging must have the tenant reference in the metadata.
In a service oriented environment central logging should always be established for SIEM and general Audit overview. So the possibility for filtering all logs for a specific tenant exists.
Sources
Banner generated with Microsoft Designer.
Top comments (0)