Hashicorp Vault Replacement Feature Design Candidate

Owned by Joseph Pearson
Last updated: Oct 24, 2023
3 min read

Status: Investigating

Sponsor User: IBM

Date of Submission: Oct 20, 2023 

Submitted by: @Joseph Pearson 

Affiliation(s): IBM

<Please fill out the above fields, and the Overview, Design and User Experience sections below for an initial review of the proposed feature.>

Scope and Signoff: (to be filled out by Chair)

Overview

On August 10, 2023, Hashicorp announced their products (Terraform, Vault, Consul, Packer, Vagrant) were transitioning from an open-source MPL license to a BSL 1.1 source-available license.  The BSL 1.1 license prevents Hashicorp products from being used as dependencies in Linux Foundation projects.  The former MPL-licensed version can continue to be used, but will no longer receive updates, fixes, and security patches after December 31, 2023.  Offering secure deployment of secrets in Open Horizon is a strategic differentiating feature, and thus this feature should not be removed from the project codebase.  An existing open-source equivalent (EnvKey) is being evaluated, but would require the following changes to be completed by mid-Q1, 2024 to be viable:

  • migrating existing configured secrets to a new solution

  • handling the Auth redirection

  • changing or rebuilding the interfaces for the CLI, Device Agent, Cluster Agent, and AgreementBots

Thus, forking the most recent MPL-licensed version of Vault and using the results as a replacement solution seems to be the best path forward.  Towards that end, this feature request is requesting that action and will detail the high-level tasks and considerations.  The TSC will be asked for approval of the formation of a sub-group to enable easier collaboration on this effort with all interested third-parties.  The TSC has voted to approve the formation of a sub-group to enable easier collaboration on this effort.  The first meeting is scheduled for November 9, 2023.

Design

<Describe how the problem is fixed. Include all affected components. Include diagrams for clarity. This should be the longest section in the document. Use the sections below to call out specifics related to each aspect of the overall system, and refer back to this section for context. Provide links to any relevant external information.>

 

User Experience

<Describe which user roles are related to the problem AND the solution, e.g. admin, deployer, node owner, etc. If you need to define a new role in your design, make that very clear. Remember this is about what a user is thinking when interacting with the system before and after this design change. This section is not about a UI, it's more abstract than that. This section should explain all the aspects of the proposed feature that will surface to users.>

 

  • Needs to be a drop-in replacement for Vault initially.

  • Need to establish a long term onboard for Vault users looking to switch as projects naturally diverge.

 

Command Line Interface

<Describe any changes to the hzn CLI, including before and after command examples for clarity. Include which users will use the changed CLI. This section should flow very naturally from the User Experience section.>

 

External Components

<Describe any new or changed interactions with components that are not the agent or the management hub.>

 

Affected Components

<List all of the internal components (agent, MMS, Exchange, etc) which need to be updated to support the proposed feature. Include a link to the github epic for this feature (and the epic should contain the github issues for each component).>

 

None, should be a drop-in replacement.

 

Security

<Describe any related security aspects of the solution. Think about security of components interacting with each other, users interacting with the system, components interacting with external systems, permissions of users or components>

 

  • Will need a dedicated method for handling CVE reporting and resolution. This may need to be separate from other Open Horizon components.

 

APIs

<Describe and new/changed/deprecated APIs, including before and after snippets for clarity. Include which components or users will use the APIs.>

 

  • None

 

Build, Install, Packaging

<Describe any changes to the way any component of the system is built (e.g. agent packages, containers, etc), installed (operators, manual install, batch install, SDO), configured, and deployed (consider the hub and edge nodes).>

 

  • New docker images will need to be produced under Open Horizon's DockerHub repository.

  • Priority will be given to core Vault services over UI, plugins, SDKs, etc.

  • Do we have requirements for multiple patch releases?

  • Do we have requirements for multiple minor version streams?

 

Documentation Notes

<Describe the aspects of documentation that will be new/changed/updated. Be sure to indicate if this is new or changed doc, the impacted artifacts (e.g. technical doc, website, etc) and links to the related doc issue(s) in github.>

 

  • Removal of Hashicorp references, including enterprise offerings.

  • Changes to responsible parties in charge of each component of the repo.

  • May need a placeholder name change such as Terraform to OpenTF.

 

Test

<Summarize new automated tests that need to be added in support of this feature, and describe any special test requirements that you can foresee.>