Enhance the Secrets for Zowe SDK to support headless (no X server running) Linux installations

[adam-wolfe]

Is your feature or enhancement request related to a problem or limitation? Please describe

Zowe CLI's secure credential storage capabilities do not work out-of-the-box in Linux installations that are not running X server (typical with minimal or server installations). We present a possible workaround in our documentation, however this is not an ideal solution and requires extra work from the user.

libsecret requires use of D-bus which is not launched automatically if a user is not running an X11 server. In order to store and retrieve credentials on Linux installations without a graphical desktop window manager, users must start a D-bus session and unlock the gnome keyring, which is not ideal and may require users to install additional software packages.

Describe your enhancement idea

Now that Zowe CLI and Explorer are using and maintaining their own implementation of keytar, is there an alternative to libsecret that does not require D-bus to be running? Can we detect that the D-bus is not available and print some kind of warning rather than trying to read credentials and failing?

Ideally, Zowe CLI would be able to handle secure credential storage in these environments without any additional work from the user, but at the very least it would be helpful to let a user know why they cannot store/retrieve credentials with a nicer error message.

Describe alternatives you've considered

There is the workaround provided in Zowe docs (https://docs.zowe.org/stable/user-guide/cli-configure-scs-on-headless-linux-os).

For automation tools (e.g., Jenkins), there are other ways to store credentials using the tools' built-in secrets storage.

Provide any additional context

[github-actions[bot]]

Thank you for raising this enhancement request. The community has 90 days to vote on it. If the enhancement receives at least 5 upvotes, it is added to our development backlog. If it receives fewer votes, the issue is closed.

[jt-nti]

+1 This enhancement would be a huge improvement for running the CLI in dev containers.

[AxelChaban]

Some customers doesnt want to use SSH on their z/OS partition, ZOWE CLI with RSE API or zOSMF could be a great improvement for their DevOps Transformation (using Gitlab CI or Jenkins).

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[jt-nti]

Bump

[adam-wolfe]

Could the Secrets SDK/Zowe CLI respond to errors using the constants listed here, such as SECRET_ERROR_IS_LOCKED and/or SECRET_ERROR_NO_SUCH_OBJECT? It would be helpful if Zowe CLI could detect that the keyring is locked, prompt for the password (hiding the input), and attempt to unlock the keyring, then do whatever action the user was trying to do (set or read secure values, then continue with the rest of the CLI command).

In C, you can do this with a system call: system("echo -n [password] | gnome-keyring-daemon --replace --unlock") - note that this would be vulnerable to command injection, so input would have to be handled carefully. I'm not sure if anything needs to be done to ensure that a dbus session is running, which might make this less feasible.

[adam-wolfe]

Could also consider an alternate backend for cred mgmt. Maybe password-store?

Another alternative would be to give users early warning if we determine that gnome-keyring cannot be accessed/is not unlocked. Currently, when users try to run a command like zowe config secure they enter values and then the command fails when Zowe CLI attempts to update stored secure values.

May be useful to implement a function in the secrets SDK to help with validating/debugging access to the keyring.