community
community copied to clipboard
zowe
A design for storage of secure CLI properties in memory can be reviewed
I opened this issue to provide the Zowe Architecture Squad the opportunity to review a design proposal for storing secure CLI properties in memory as an alternative to using the Secure Credential Store.
No immediate implementation of this design is planned. However, if such a feature becomes a higher priority, this is the design that the CLI team will follow to implement that feature.
The design document can be viewed from the Zowe CLI repository:
https://github.com/zowe/zowe-cli/blob/master/docs/Design_for_in-memory_storage_of_secure_CLI_properties.md
If the Squad feels that this topic needs to be discussed in an Architecture Squad meeting, it can be added to the Squad's agenda and the timing of any such meeting can posted as a comment to this issue.
The CLI team is currently evaluating the right approach for replacing the soon-to-be-retired Keytar component of the Secure Credential Store. For backward compatibility, other technology may be used instead of the items described in this document. If other technology is used, it will be described in its own design document, and this document will evolve into a record of alternative technology that may be of value for future encrypting needs.
Until that decision is finalized (at least several weeks), I will leave this issue open.
The referenced design document has been repurposed to be a record of the research into NodeJS crypto techniques that could be used to store secure properties to disk.
Many of the previous use-cases were modified. The use of daemon mode was removed. The record of our investigation into the underlying crypto technology remains.
Those updates will allow this documentation to remain as a relevant historical document, as we pursue another approach to storing secure data. The revised document, which retains the record of our investigation into NodeJS crypto functions, will replace the existing design document as soon as it is reviewed & approved by the Zowe CLI team.
The CLI team's proposed approach for storing secure properties will be presented to the Zowe Architecture Squad in an upcoming squad meeting. I will keep this issue open until that meeting. Design documentation for the CLI's proposed approach will likely follow in the future.
Is the new document to be reviewed https://github.com/zowe/zowe-cli/blob/master/docs/Design_for_securing_CLI_properties_with_NodeJS_Crypto.md ?
Is the new document to be reviewed https://github.com/zowe/zowe-cli/blob/master/docs/Design_for_securing_CLI_properties_with_NodeJS_Crypto.md ?
No it is not. That document is now a record of technology that we investigated but which we do not currently plan to use as a replacement for Keytar. We relabeled the document so that we did not lose the information that we gathered.
The CLI team has a different plan for Keytar replacement, In the January 10 meeting of the Architecture Squad, I will present the options that we considered and identify the option that we plan to implement. A detailed design of that option will be started in January.
The following spreadsheet records the analysis performed in determining the approach for replacing Keytar in the Zowe CLI. It will be the source of discussion for the Jan 10 Architecture Squad meeting. Keytar replacement options spreadsheet.pdf
Also attached a summary of the discussion of each option which led to our conclusion. Keytar options summarized.pdf
@KUGDev and the IntelliJ team:
As you may know, the Zowe CLI provides a Secure Credential Store (SCS) for storing secure properties in persistent storage. Our SCS uses a third party component named Keytar, which actually stores the data in the OS's secure vault. The Keytar component has been decommissioned. Our team is starting an effort to replace Keytar. Our approach is to implement a plug-compatible API in the Rust programming language.
Our analysis of this replacement is included in this GitHub issue.
During a Zowe Architecture Squad review of our analysis, it was suggested that since your IntelliJ team may be investigating secure storage yourselves, we should probably share our information on this topic with you.
This is NOT a request for you to conform to our approach. Even if our CLI technology does not apply to your needs, we felt that you should be aware of the problem that we uncovered and the options that we considered.
With the completion of a review meeting by the architecture squad, I am closing this issue.