Open xorima opened 2 years ago
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
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 calledprivate 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 assshPrivateKey
Proposed solution
Extend the
OnePasswordItem
spec
to have akeyMutation
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 thankeyMutation
was selected we could also use that to enforce that certian keys must exist else the operator would error to reduce human errorThis would look like:
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 thepublic key
being just given to you, so if you update the key you would need to ensure you update everything accuratelyReferences & Prior Work
https://learn.hashicorp.com/tutorials/vault/kubernetes-sidecar#apply-a-template-to-the-injected-secrets