Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.



Page Properties


Status

Status
colourGrey
titleon pause

Stakeholders

All developers, SysOps, Hosting providers

Outcome
Created date

  

Owner




Note
titleNOTICE

This decision has been migrated to the Technical Council's Decision Log as part of a consolidation effort.  See:   DR-000030 - FOLIO Secrets Management


Table of Contents

Changes list

...

References

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyFOLIO-2278

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODORGSTOR-33

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODINREACH-19

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODPUBSUB-78

...

Option 2 - Inject secrets during container creation

Draft visualization

Drawio
bordertrue
diagramNameFOLIO secrets management opt 2
simpleViewerfalse
width750
linksauto
tbstyletop
diagramDisplayName
lboxtrue
diagramDisplayName
diagramWidth775
revision5

Solution components

  • FOLIO modules can read secrets from sidecar agent from well-known and standard place (e.g., Environment Variables, hereafter EV) and use them
  • secret-storage agent is a jar-library supporting different container type details and move secrets from container-specific paths to EV
    • it is aware about specific details of particular container types and is able to read them
      • take secrets from environment variables for clean docker
      • use environment variable or mounted data volumes for Kubernetes Secrets
      • retrieve secrets from AWS SSM for cloud-based installation
    • pure Java enables both Vert.x and Spring support
    • potentially, it can be able to support additional functionality, e.g. runtime secret updates via event/callback mechanism if this feature is supported by container type, etc.
  • pre-deployment script is a part of container building process which is responsible for retrieving secrets from particular Secret Storage and injecting them into containers
  • Devops / Administrator uses specific secret storage provider UI for secrets management

...

Drawio
bordertrue
diagramNameFOLIO secrets management opt 3
simpleViewerfalse
width700
linksauto
tbstyletop
diagramDisplayName
lboxtrue
diagramDisplayNamediagramWidth742
revision4


  • secret-store-agent (or client) as a pure Java library available for both Vert.x and Spring
  • Module edge-api-utils (https://github.com/folio-org/edge-api-utils) currently presenting common / shared Edge API utilities for edge-common and edge-common-spring can be used as a basis for secret-store-agent and be enriched with new functionality
  • secret-store-agent provides an abstract unified interface (for connecting to Secret Store and work with secrets) and an extendable number of particular implementations
  • CRUD support makes sense (see cases A and B from Craig's comment below)
  • >> How does authentication and authorization fit into these models? For example, can every module access every secret? does each module access the secret store with different credentials?
    • secret-store-agent in every module should be configured separately
    • each module (more precisely - each secret-store-agent) can access the secret store with different credentials; this can be managed via
      • Vault Token https://www.vaultproject.io/docs/concepts/tokens which can be mapped to a set of one or more attached policies. In turn, these policies control what the token holder is allowed to do within Vault. Note that usage of root token in production is not recommended
      • AWS IAM role
    • another option is to manage access on application level, e.g. every module has own static key (or token, or salt) that is used as a part of secret key
  • Multi-tenancy support - all the secrets are to be accessible per tenant level

    • it's possible to add secrets for a new tenant without module(-s) restart
  • Secrets can be cached with defined TTL by secret-store-agent (under discussion - caching is not the best practice for secrets)
  • Logging and audit
    • via native Secret Store provider capabilities
    • still FOLIO-centralized option is possible if need
  • Certificates (e.g., for Kafka clients) are to be provided and mounted externally as JKS while secret-store-agent can be used to manage keystore & truststore location and password

...

  • (plus)  Share this document for very early review
  • (plus)  Find FOLIO devops expert(-s) to review some technical capabilities and ideas
    • Current approach implemented in edge-common still looks good
  • (plus) On Tech Leads meeting:
    • how important and priority this task is?
    • present the work done and current state
    • collect known requirements to FOLIO secrets management
    • receive an early feedback on which of proposed options looks more preferable
  • (plus)  Collect feedback, remarks, notes and thoughts offline
    • Raman A: aggregate them, react on potential action items
  • Tech Leads meeting
    • review updates
    • Proposed next steps
      • check with DevOps regarding Kafka certs configuration
      • rename once again (sorry for that) in secret-store-agent to be widely used
      • use
        Jira Legacy
        serverSystem JiraJIRA
        serverId01505d01-b853-3c2e-90f1-ee9b165564fc
        keyMODORGSTOR-33
        to add C.UD support

...