| Table of Contents |
|---|
This page is aimed to consolidate and document all known requirements (both functional and non-functional) applicable to FOLIO secrets management.
Use cases we want/need to support
...
Use cases
A user (administrator?) wants to create/manage secrets through the secret storage directly and allow folio FOLIO modules to access those secrets - here we only need (read-only support, right? This is essentially how the edge APIs handle this today.
Case where aaccess)
- A user (administrator?) wants to create/manage secrets through folio. For exampleFOLIO. E.g., a module might need to store credentials to some external system (I think the invoice app stores FTP like FTP or SMTP server credentials, and I'm pretty sure organizations also stores some sensitive information). Other examples include things like smtp server credentials, knowledge base API keys , etc. These are things that are set/managed by users via the FOLIO UI, e.g. settings, etc.Case where modules want UI forms are involved as well for interaction with a user
- A module wants to create/manage secrets - the so that a user is not even in the loop here. The , and the interaction is only between the module and secret storage. I think this is a real use case. For instance some modules Examples are modules which are creating system/tenant users , (like mod-pubsub. My understanding is that we want to move away from that and develop a formal solution for system/tenant users. Another example is auth - ), 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.
NOTE: If we're going to support (2), we'll be sending secrets over HTTP REST calls - While client -> folio transactions are likely over HTTPS, internal communication is still using HTTP, so the secrets will be in plain text when proxied from OKAPI. Maybe this isn't a huge deal? I think the assumption is that FOLIO is probably running in a private network.
Secret types
...
Secret types
The following secret types are to be supported:
| Secret type | Format | Notes | |
|---|---|---|---|
| login & password | String | runtime + at start; per tenant | |
| API keyskey | String | ||
| SSL certificate | file | Cannot be stored in SSM, Vault etc. Encrypted S3? |
Who creates? Who should have access? How does it work now?
Secret stores to be supported
The following secret stores are to be supported:
| Secret store mechanism | Links | Environments or needs |
|---|---|---|
| HarshiCorp Vault | https://www.vaultproject.io/ | on-premises installations |
| AWS Systems Manager Parameter Store ( or just AWS SSM) | https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html | AWS cloud hosting |
| properties-file | for dev/test needs | |
| environment variables |  | |
K8S secrets | |
Secrets management UI - home-grown unified web UI vs. store-specific UIs
...
Both AWS SSM and Vault have their own management user interfaces, Rancher provides an option to manage secrets in form of environment variables in UI forms.
FOLIO tech stack support
List of The following programming languages used on Folio platform are to be supported:
Java Spring way- Java VerVert.x
- Node.js (RA: I haven't met such modules/components by my own but have heard they exist - is is so, and should they be considered?)
- are there any other languages used?
...
Access to secrets must be logged for further audit.
- 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
- 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
...
Any particular FOLIO module should only have access its own secrets.
Notes:
- check AWS ssm:GetParameters permission - it is the policy used to enforce access control and protect one service’s secrets from another (here is a good overview of this process https://aws.amazon.com/blogs/mt/the-right-way-to-store-secrets-using-parameter-store/)
- on Vault access can be managed via roles, tokens etc. (https://www.vaultproject.io/docs/auth)
Multi-tenancy support
A tenant should only have access its own secrets
Notes:
...
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?
Caching secrets
Can / should secrets be cached in apps?
...