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

      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

      JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODORGSTOR-33

Secrets access type

Is read-only access enough to cover use case #1 from above, or full access with CRUD support to cover use cases #2 and #3 is mandatory?

Secret types

The following secret types are to be supported:

...

• Option 1 - Use secret stores native audit capabilities
  
  • https://docs.aws.amazon.com/systems-manager/latest/userguide/logging-and-monitoring.html
  • https://www.vaultproject.io/docs/audit
  • No development, just devops/hosting
  • Access to properties files or System Environments won't be have such native audit capabilities
• Option 2 - FOLIO dedicated log storage
  
  • e.g., based on mod-audit or a new one - just a unified way regardless of hosting details
  • Development is required

...

• tenant are FOLIO internal term, so that it seems now that access verification on tenant level cannot be supported on Secret store level
• tenant ID can be used as a part of secret name

Secrets update in runtime

Adding new secrets (even for a new tenant) should be available without restart

Secret update in runtime

Are there specific requirements to runtime updating for secrets? I.e. should consumers be able to update secrets in runtime without restart/downtime/ updating tenant's secrets in a multi-tenant environment shouldn't result in downtime for other tenants, if possible.

Secrets updates can be challenging because of more complex mechanism of change notification, e.g. in case of password change or rotation - how to ensure that all instances are notified and use the recent value?

Caching secrets

Can / should secrets be cached in apps?

...