1Password / onepassword-operator

The 1Password Connect Kubernetes Operator provides the ability to integrate Kubernetes Secrets with 1Password. The operator also handles autorestarting deployments when 1Password items are updated.
https://developer.1password.com/docs/connect/
MIT License
531 stars 60 forks source link

Be able to rename keys from 1Password #128

Open xorima opened 2 years ago

xorima commented 2 years ago

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

havard024 commented 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

xorima commented 2 years ago

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

achernar-iconik commented 1 year ago

I am having the same issue with ArgoCD!

xorima commented 1 year ago

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

Hobbit44 commented 8 months ago

This could be achieved with this is believe: https://github.com/1Password/onepassword-operator/issues/69

bdsoha commented 4 months ago

+1