Page Comparison

This page is aimed to consolidate and document all known requirements (both functional and non-functional) applicable to FOLIO secrets management.

Use cases

1. A user (administrator) wants to create/manage secrets through the secret storage directly and allow FOLIO modules to access those secrets (read-only access)

   1. No specific Jira examples though as per my understanding all those secrets being specified in modules' ModuleDescriptor-template.json files (in launchDescriptor.env section, e.g. DB_USERNAME, DB_PASSWORD etc.) fit this category
2. A user (administrator) wants to create/manage secrets through FOLIO. E.g., a module might need to store credentials to some external system (like FTP or SMTP server credentials, API keys etc.) UI forms are involved as well for interaction with a user
   
   1. Example: INN Reach Central Server Configuration keeps API keys (key and secret) for Central and Local servers. As per requested behavior, UI Screen contains fields for setting / displaying API keys, and a user (administrator) uses them to save, view or update keys. One can use

      Jira Legacy
      server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UIINREACH-12

      for reference and find mock ups there. Currently, backend module storage is used to store such keys
3. A module wants to create/manage secrets so that a user is not even in the loop here, and the interaction is only between the module and secret storage.
   1. Examples are modules which are creating system/tenant users (like mod-pubsub), or a case with generating and storing signing keys in such a way that all instances of the mod-authtoken container can easily stay aligned
   .
   2. One more specific example is

      Jira Legacy
      server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODORGSTOR-33

Secret types

The following secret types are to be supported:

...