Explore direct frontend communication with OpenBao

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

Currently, all secret operations go through the Rails API. We want to explore having the frontend communicate directly with OpenBao for secret value updates while still using Rails API for metadata updates.

Proposal

Design a workflow where the frontend makes two sequential requests with independent version checking: one directly to OpenBao to save secret values, and another to Rails to update metadata.

Implementation details

  • Determine how frontend will authenticate directly with OpenBao
  • Design a workflow for two sequential requests with proper error handling:
    1. Frontend directly updates secret value in OpenBao
    2. Frontend calls Rails mutation to update metadata
  • Update the Rails mutation to no longer accept secret values since the frontend will handle this directly with OpenBao
  • Implement proper version checking for both operations to handle potential race conditions
  • Consider UI design that makes the distinction between saving values and metadata clear
  • Evaluate having separate UI controls for saving metadata/permissions vs. saving secret values

What does success look like, and how can we measure it?

  • Frontend can securely communicate directly with OpenBao for value updates
  • Metadata updates are still properly validated through Rails
  • The UX remains intuitive despite the split update process
  • Race conditions are properly handled with appropriate user feedback

Why is this needed?

Currently, all secret-related operations flow through our Rails API, creating potential bottlenecks when handling numerous secret operations. By enabling direct communication between the frontend and OpenBao for secret value operations, we can:

  1. Reduce load on the Rails server by offloading some operations directly to OpenBao
  2. Improve performance for secret read/write operations by eliminating the Rails API as an intermediary
  3. Enhance security by reducing secret value exposure - secret values no longer pass through the Rails layer, minimizing the attack surface
  4. Create a clearer separation of concerns where:
    • OpenBao handles secret value storage and retrieval
    • Rails handles metadata validation, permission management, and business logic

This represents a strategic architectural shift toward a more distributed responsibility model where appropriate operations bypass the Rails layer. The implementation requires careful handling of versioning to prevent race conditions, which is why this depends on proper CAS support for both secret values and metadata.

Edited by 🤖 GitLab Bot 🤖