HN Explorer

Ask HN: Why most CLIs are not using keyring?

19 points by eris_agx ↗ HN
This is bit of a rant on software usability and security. CLIs like kubectl/awscli/<add your critical tool here> don't use keyring to store credentials, instead using plain text files. Besides requiring me to retype passwords over and over.

Any good reason to avoid keyring? Please enlighten me

FYI: I've learned today that poetry (the python thing) uses keyring for credentials. Good job!

9 comments

[ 4.9 ms ] story [ 36.3 ms ] thread
[deleted]
(comment deleted)
viraptor
Don't know about kube, but awscli and a few others decouple the idea of getting credentials and doing the actions. You can use the password directly through them every time, but a better way is to either use the preconfigured profile or some wrapper which does use the keychain. For example https://github.com/99designs/aws-vault/ supports one-off commands and shell sessions with pre-populated tokens. There's also similar cf-vault.

Terraform also can be configured to use environment variables (and I'm sure other utilities) which allows similar "use a separate tool for creds" approach.

(kube apparently has https://github.com/chrisns/kubectl-passman)

perryizgr8
What's a keyring?
shoo
by "keyring" we probably informally mean some service offered by an operating system / desktop environment to securely store credentials (passwords, keys, etc). e.g. for macOS this is "keychain access" (https://support.apple.com/en-au/guide/keychain-access/kyca10... ).

Different desktop operating systems implement various versions of this, calling it different things, with different APIs to use them. If you use a desktop app (e.g. browser, email client) in a popular operating system and it saves your user credentials somewhere, it should probably store them in the operating system's keyring service.

There is a python library named "keyring" that python applications can use to access them, in an aspirationally cross platform way https://pypi.org/project/keyring/

3np
Might be a bit of a chicken-and-egg-thing but the org.freedesktop.secrets options on Linux are still not satisfactory and a blocker for adoption IMO.

AFAIK the only mature enough implementations are those available in linux repos, namely gnome-keyring, kwallet (KDE), and keepassxc. So it's not really an option for many use-cases. Backups and syncing are hacky or badly supported and documented. Granular control likewise. I don't recall the details right now but IIRC the API itself had some problematic and/or annoying aspect to it when I looked into it. I also suspect that for many, dbus does not spark joy and relying on it for secrets is not attractive.

There are some early implementations I'm aware of that might work in practice and with enough engagement could become viable:

  https://github.com/yousefvand/secret-service
  https://github.com/mdellweg/pass_secret_service
  https://github.com/nullobsi/pass-secrets
I'm also keeping an eye out on Himitsu, which I guess you could say is attempting a more holistic approach: https://himitsustore.org/
mkj
At least with gnome-keyring, it doesn't seem able to limit keyring access to only "good" program executables (how would it identify them? And their linked libs...), so using the keyring won't give much security benefit?
[deleted]
(comment deleted)