Be able to rename keys from 1Password
Summary
The keys in the secrets come directly from 1password, there are times at which changing these key names is very desirable.
Use cases
ArgoCD wants to consume a secret in a well known format to be able to connect via ssh to a repository.
1Password has a SSH Key secret type which is stronly opinionated that the private key is stored in a field called private key and is not renamable.
To be able to resolve this (and I am sure there are other times at which removing the hard coupling between field name and secret key) I want to be able to say that key name: private key should be put in the secret as sshPrivateKey
Proposed solution
Extend the OnePasswordItem spec to have a keyMutation property which would allow us to do to/from today but also enable further changes down the line if desired (such as a regex match for large scale changes across a lot of values at once).
If a different name than keyMutation was selected we could also use that to enforce that certian keys must exist else the operator would error to reduce human error
This would look like:
apiVersion: onepassword.com/v1
kind: OnePasswordItem
metadata:
name: example
spec:
itemPath: "vaults/<vault_id>/items/<item_id>"
keyMutation:
- key: "private key"
action: rename
value: "sshPrivateKey"
I cannot currently think of other actions to perform but I feel by leaving this in there (or maybe leaving it as a documented default) then if other usecases come up this could easily be extended to those usecases.
Is there a workaround to accomplish this today?
You can store ssh keys outside of the ssh key object in 1password, but you then lose all the value given by that key type, such as the fingerprint and the public key being just given to you, so if you update the key you would need to ensure you update everything accurately
References & Prior Work
https://learn.hashicorp.com/tutorials/vault/kubernetes-sidecar#apply-a-template-to-the-injected-secrets
I have the same issue using FluxCD, which expects the private key in the identity field
It would be great if you can rename / choose the field name you want to use in the SSH key object, until then, my workaround is to still use the SSH key object then add another field and copy the ssh key inside of it
Yep, my other thought is the same secret could be used by multiple apps requiring different names. While yes a different secret for each would be better we all know that isn't always practical or possible
I am having the same issue with ArgoCD!
So my ultimate fix for this was to stop using the 1password operator and start using ExternalSecrets as their onepassword integration is better than 1password's integration
This could be achieved with this is believe: https://github.com/1Password/onepassword-operator/issues/69
+1