-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be able to rename keys from 1Password #128
Comments
I have the same issue using FluxCD, which expects the private key in the It would be great if you can rename / choose the field name you want to use in the |
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: #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 than
keyMutation
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
The text was updated successfully, but these errors were encountered: