[
https://issues.apache.org/jira/browse/FINERACT-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1833:
-------------------------------------------
Description:
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 received already 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.).
was:
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 received already 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.).
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.).
> 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.9.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 received already 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)
