[
https://issues.apache.org/jira/browse/FINERACT-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1833:
-------------------------------------------
Fix Version/s: 1.10.0
(was: 1.9.0)
> Extension point: application.properties based multi-tenancy
> -----------------------------------------------------------
>
> Key: FINERACT-1833
> URL: https://issues.apache.org/jira/browse/FINERACT-1833
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: Aleksandar Vidakovic
> Assignee: Aleksandar Vidakovic
> Priority: Major
> Fix For: 1.10.0
>
>
> At the moment Fineract's multi-tenancy feature is based on a separate tenant
> database with a single table; each row contains the database connection
> details and timezone settings for each tenant. I am proposing to make this
> feature an official Fineract extension point and to provide an alternative
> implementation based on application.properties instead of the database
> approach.
> Using application.properties is - for a Spring Boot - the best place to put
> any kind of application configuration. Since Fineract's inception a lot has
> happened in the Spring/Boot eco-system. Reloadable configurations are nothing
> strange anymore and a solved problem. In fact, they are especially useful
> when applications are deployed in a Kubernetes environment and ensure that
> Fineract's application context is always in a correct state. A recent example
> where this was applied was in the fix for a file traversal vulnerability
> related to ContentRepository (see FINERACT-1794). Instead of using the JDBC
> based ConfigurationService we moved the configuration for file system and S3
> based file storage to application.properties. This makes life immediately
> easier for everyone, we removed another point of failure (the database) and
> we laid the ground to make this a true extensible feature (watch this space,
> we have a proposal to add Azure Storage) without having to deal with database
> schemas and Liquibase migrations. It is so much easier just to deal with the
> properties files and to adapt them if needed.
> To ensure that configuration information is separated by tenant we would not
> store everything in the default application.properties file. Obviously we
> don't know yet which tenants users want to add; and if we stored the tenant
> information in that file we would need to constantly (well, every time we add
> a tenant) overwrite that file. This would be at the least very annoying,
> because this file is under Git control, means: when the next release upgrade
> needs to be applied then there is a potential for dropping the ball and
> someone overwrites your tenant configuration. Instead, each tenant's
> configuration would be provided in a separate Spring Boot profile
> configuration, e. g. the default tenant's configuration would be provided in
> a file named "application-tenant-default.properties". The prefix
> "application-tenant-" is a convention that everyone should follow. We might
> have later other features that could use profile configurations and/or custom
> modules might use these (profile) mechanics too. Just to avoid any
> collisions. This file based tenant configuration approach would allow you to
> easily add and remove (e. g. via Docker volume mount for the files and a
> simple command line parameter for Fineract's startup command via
> "-Dspring.profiles.active=default,tenant-default,tenant-abc,...") additional
> tenants in a way that is very likely more "natural" for your DevOps people,
> having to deal with configuration in a database is a bit of a distracting
> context switch.
> And finally: the current approach has also some security related issues. The
> credentials for the tenants' database connections are stored in plain text
> which is pretty much a no-go (and we've already received requests from
> community members to address this issue). If we move this to the properties
> files then you can use pretty much any sensible strategy that is available
> today to safely store credentials like vaults (Hashicorp Vault, Kubernetes
> Secrets) or environment variables for example. These approaches are also
> first class citizens supported by Spring Cloud (Kubernetes Secrets, vaults
> etc.). The current database configuration also doesn't allow to properly
> separate concerns between DevOps and developers (the database migration is
> maintained in Git which means under the developers' control). Usually you
> would want to keep this apart from each other.
> And no worries, there are no plans to remove the current way how tenants are
> configured, but I think it would be a good idea to default to the easier and
> more secure approach (properties) and still leave an option for those who
> can't or don't want to switch. The idea is also to provide some help with
> migrating your existing tenants to properties files. There could be some
> migration component that can help creating the necessary files (details to be
> defined), e. g. when the application boots up in the log messages (similar
> how Spring Boot does it if there are e. g. configuration properties changes
> etc.).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
