[FOLIO-2583] Spike: Distributed configuration Created: 04/May/20  Updated: 28/Aug/20

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Story Priority: P3
Reporter: Craig McNally Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-2565 Misleading Permission Set Configuration Closed
relates to MODOAIPMH-243 update edge module institutional user... Closed
Sprint: CP: Non-roadmap backlog
Development Team: Core: Platform

 Description   

Overview

One outcome of FOLIO-2565 Closed is that centralized configuration via mod-configuration is problematic from a security perspective. It provides a convenient mechanism for storing configuration, but the permission granularity is too coarse. Granting a user the ability to access an entry for one app means that they will also have access to ALL configuration entries.

An idea was proposed that all modules have a system interface which can be implement (or not), that presents a common interface for accessing configuration specific to various modules.

e.g. each module would have the opportunity to implement the "config" interface and implement:

  • GET /configurations/entries
  • GET /configurations/entries/<id>
  • POST /configurations/entries
  • PUT /configurations/entries/<id>
  • DELETE /configurations/entries/<id>

Each of which would be protected by discrete permissions, e.g. mod-foo might have:

  • foo.configurations.collection.get,
  • foo.configurations.item.get (put/post/delete)

Acceptance Criteria

  • The following questions should be answered
    • Feasibility of this idea - a POC might make sense
    • What would adoption of this look like? Is an opt-in model viable?
    • Are there other aspects to this that should be considered in the decision making process?
      • Sample/Reference data loading - seems like a win to me over centralized configuration
      • Default implementation by RMB? Reference implementation?
      • Impact to the UI?
      • Optional use of permissionsDesired to offer even finer grained access control?
      • Ability to incorporate secret storage (encryption at rest) in the future, i.e. via extension of this API?
  • Documentation of the high level design on the wiki
  • User stores are created for implementation


 Comments   
Comment by Taras Spashchenko [ 15/May/20 ]

It looks like I did not comprehend the goal of implementing this distributed configuration.
As for me, the configuration itself is not a part of a module, and it can’t be provided by any other FOLIO modules, because usually configuration parameters are needed at the initialization stage of the module’s lifecycle less often during other module's activities. But there is no guarantee that the configuration module itself already completed its starting when a module requires configuration params at the initialization phase. The good solution here is to use externalized configurations (https://microservices.io/patterns/externalized-configuration.html). It can be achieved in two ways. Either all configuration params are provided as environment variables to a module at start-up or there can be a dedicated configuration server that is not a part of the FOLIO, and each FOLIO module just connects to it to read its configurations. There is a wide variety of production-grade solutions for this like ZooKeeper, Consul, etcd. Vault can be used to leverage secure storage, etc. If we are talking about K8S it provides “Config Maps” and “Secrets” out of the box for providing configuration capabilities. We even can use a simple Spring Cloud Config Server and just learn RMB how to deal with that. Behind the Spring Config Server, there can be any configuration provider starting from flat properties files to the git repo and others.
So, what I want to say is that there are many solutions already available to us. So we do not have to reinvent the wheel, just work out criteria and requirements and select a solution that suits best our needs.

Comment by Craig McNally [ 28/May/20 ]

Taras Spashchenko how would external configuration storage work with permissions? The main challenge we face here is that the permissions in mod-configuration are not granular enough. You're either able to access all config entries, or none of them. By distributing the configuration we're able to better control who can access which configuration entries... i.e. a user might need to access orders configuration but not SAML or email configuration.

That's not to say that we the underlying storage can't be some external system, but users shouldn't be able to go directly to that storage to access configuration, otherwise we're back to all or nothing access.

Comment by Craig McNally [ 27/Aug/20 ]

See https://folio-org.atlassian.net/wiki/display/DD/Distributed+Configuration

Comment by Taras Spashchenko [ 28/Aug/20 ]

Thank you.

Generated at Thu Feb 08 23:21:44 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.