Unable to get secret by key

[toksdotdev]

Steps To Reproduce

At the moment, getting a secret is only possible by the id:

client.secrets().get(&SecretGetRequest { id: "some uuid".to_owned() }).await;

Expected Result

I should be able to retrieve secrets by the key I provided at creation. I feel the key should be honored as a means of retrieval since that’s what’ll be known to the caller and not necessarily the secret id.

Actual Result

At the moment, a work around is to:

• Fetch all the secrets,
• Filter by the key, and
• Refetch the clear secret.

Not having to filter manually by the secrets will be a huge improvement.

Screenshots or Videos

No response

Additional Context

No response

Operating System

macOS

Operating System Version

No response

Build Version

0.2.1

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[larivierec]

i second this, i just recently tried to use this and integrate with external-secrets and since we can only go by ID, it's a little harder to read if i were to deploy the helm-release + i'd need to know the exact secret id by listing them all first.

ideally, with a key, it would be easier

[Cubea01]

i second this, i just recently tried to use this and integrate with external-secrets and since we can only go by ID, it's a little harder to read if i were to deploy the helm-release + i'd need to know the exact secret id by listing them all first.

ideally, with a key, it would be easier

I'm trying to configure this as well. Do you still have your helm/flux yamls for your attempt I can use as a reference?

[larivierec]

i second this, i just recently tried to use this and integrate with external-secrets and since we can only go by ID, it's a little harder to read if i were to deploy the helm-release + i'd need to know the exact secret id by listing them all first.
ideally, with a key, it would be easier

I'm trying to configure this as well. Do you still have your helm/flux yamls for your attempt I can use as a reference?

yes, however, i've used bw cli to expose the restapi.
https://github.com/larivierec/home-cluster/tree/main/kubernetes/apps/kube-system/external-secrets

[CanRau]

Asked basically the same over at bitwarden/sm-action#20 I think this is a really necessary feature, at least for me to really adopt, the ids are too ambiguous, having to manually map them is unnecessary maintenance and having to list all, filter etc is also unneeded work.

[akash07k]

I too vote for this, accessing the secrets via ID is a very clunky way and not efficient at all

[CanRau]

Getting closer:

The team is currently evaluating the retrieval of secrets by name for consideration in a future release.
As an initial improvement, the process of retrieving the UUID has been streamlined and is now conveniently displayed below every secret.

From https://twitter.com/Bitwarden/status/1708894990766895280?t=8IAjXjcBB8uNHGOcSMvp9w&s=19

[akmalharith]

Recently moved my personal lab environment secrets to Bitwarden Secrets Manager, and suddenly noticed this limitation. I uploaded my wrapper script here https://gist.github.com/akmalharith/60c1b90e69dc622131d74c4311e6015c

But it will not be efficient if you have too many secrets.

[CanRau]

interesting approach, maybe it could accept multiple keys and make them available? not tooo proficient in bash 😅 just a thought, currently no time to play around