I have been testing the 1password CLI (along with secrets automation, ssh and other things) for personal things but also with the idea of increasing use at
$dayjob and everything is working great except for the CLI when used in interactive scenarios (like Kubernetes
ExecCredential and aws
credential_process) where the secret needs to be returned regularly and quickly. Obviously if your session has timed out or the desktop app requires unlocking the first access will be slow while you authenticate but the cache should provide fast access to the secret after the first time.
I will quickly outline my setup (identical experience on multiple machines):
pam_u2fto use Yubikey to authorise
My investigation started after I started testing this script that I use in the context of a Kubeconfig file to get the mTLS certificate and key for a k3s cluster. This was fine in Lens (it spawns a kubectl proxy which caches the credential until expiry) but when using the kubectl CLI it makes a request every time and it was a noticeable delay on each request (tab completions are particularly horrible). After testing I discovered that the requests to the 1password CLI (
op read) were cumulative and I refactored the script to use only an
op item get and then use
jq to retrieve the values I needed and create the json blob to be returned. General observation from this, a single secret get command will take between 1.3 and 1.5 seconds to complete.
I started testing this with some canned commands and the time builtin to zsh. I also set
export OP_DEBUG=true to run the following:
time op read --cache --account my.1password.com op://Private/e2hylxuji3mpog34p5ngf47uvi/public_key
After a few tests and seeing a noticeable pause in the debug output, I also fired up wireshark and screen recording to see if I could see the client making requests to 1password's servers and see if anything correlates. The following are screenshots from the video and hopefully this will be helpful in working out timings and looking at places that things can be optimised:
First, instant output from the
TCP connection open to one of the 1password service IP addresses:
The next set of requests/responses appeared seemingly all at once with the log output on the right. At this point the requests to 1password service have taken at least 884m even though the log messages appear to indicate it has found cache hits all round:
Secret returned in 1.426 seconds:
After this there are connections closed in wireshark.
Overall I think that even if the cache is being used there is a synchronous set of requests to the 1password service that the process will wait for before returning. Can this be looked into please? Please let me know if you require any more details.
1Password Version: 8.9.4
Extension Version: Not Provided
OS Version: Manjaro Linux
Browser:_ Chrome/Wavebox (Chromium Based)