Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hashicorp Vault wallet implementation proposal #568

Open
TsvetanG opened this issue Dec 4, 2023 · 12 comments
Open

Hashicorp Vault wallet implementation proposal #568

TsvetanG opened this issue Dec 4, 2023 · 12 comments

Comments

@TsvetanG
Copy link

TsvetanG commented Dec 4, 2023

Currently, the fabric operation console wallet implementation uses the local browser storage to store the user identities (cert and private key). The console user must download those identities locally to persist them. This can be a cumbersome process that requires additional steps to keep the downloaded data secure.
Hashicrop Vault can be used to persist automatically the user identities and keep the data secure without the need to download and manage locally.
The fabric operations console wallet can be extended to support Hashicorp Vault as a secure store of the user identities.
The idea is to abstract the existing wallet implementation and introduce a new Hashicorp Vault based wallet. Furthermore, a configuration can be enabled to control what wallet impl to use based on the specific deployment needs. That way the console would support the current wallet impl and the new Hashicrop Vault based impl.
My team at Senofi is willing to contribute the implementation to the project.

@dshuffma-ibm
Copy link
Contributor

@TsvetanG thanks for the proposal, so what i think we could do is make the wallet more plug-able/modular. we could make a spec that a wallet would need to implement, and a user could configure their console to use 1 of many wallets, which could include hashicorp. the actual wallet code would sit in it's own repository, and it would be pulled into a console build when we bundle the fontend js.

i like the idea of this plug-able wallet solution, because ALL users don't have to download code and get maintenance updates from every different wallet implementation, when they are only using 1 particular kind.

@dshuffma-ibm
Copy link
Contributor

so next steps would be to define the wallet api spec, and make some stubs to bring in other wallets during our esbuild process

@TsvetanG
Copy link
Author

TsvetanG commented Jan 12, 2024

Yes, we are working on the technical details and a plan. Our existing impl is not using modules so we need to do a small re-work.

@TsvetanG
Copy link
Author

@dshuffma-ibm Do you think we should be adding the Wallet vault implementation inside the fabric operations console git repo or we should use a dedicated repository?

@dshuffma-ibm
Copy link
Contributor

@TsvetanG a dedicated repository

@TsvetanG
Copy link
Author

TsvetanG commented Mar 6, 2024

Here are the technical details.
In a nutshell the idea is to change the Fabric Operations Console front-end and backend so that it can support other identity storage (Hashicorp Vault). The following changes may achieve that:

  • Change in Fabric Operations Console front-end
    The current wallet is implemented in the front-end and uses the browser storage. Hashicorp Vault based wallet impl will be implemented in the backend. Hence the front-end should be able to use backend wallet API to perform the identity(wallet) related operations. The abstraction of the wallet impl will happen in the backend using modules (see further below). In order to keep the current browser based wallet impl working a new class IdentityStorageFactory will be introduced. The IdentityStorageFactory (based on a configuration) will either use the exisitng browser storage impl or call the wallet backend APIs. The new factory class will be used by the existing IdentityApi class.

  • Implementation of Wallet REST API on the backend of Fabric Operations Console
    Implement a new wallet API that will handle the requests from the front-end (in case the front-end it is configured to use the backend based Wallet APIs). The new endpoint handlers will use an external module which provides a wallet storage client. The client will be abstract. The proper specific wallet module configuration can be provided during build/deployment.

  • Implementation of a module which provides the wallet storage
    The implementation of the wallet can exist and be maintained outside the console. This module will be a separate node_module and will be installed in the console as an external module.

@dshuffma-ibm : let us know what you think.

@denyeart
Copy link
Contributor

denyeart commented May 6, 2024

@ckpaliwal What are your thoughts?

@ckpaliwal
Copy link
Contributor

@TsvetanG
I'm weighing my options and will let you know.

@TsvetanG
Copy link
Author

@ckpaliwal Do you have any update?

@denyeart
Copy link
Contributor

Discussed with @TsvetanG today. Current thinking is to keep the implementation simple by having console repository natively support both the browser storage and Hashicorp vault storage, with a simple configuration that determines which will be used.

@TsvetanG
Copy link
Author

Pull Request ready for review #781

@TsvetanG
Copy link
Author

TsvetanG commented Oct 8, 2024

@dshuffma-ibm Thanks for merging the pull request to the experimental branch. Could you also start the build so we can get the images published?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants