Skip to content
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

Allow referencing individual fields of a 1password item #69

Open
lhriley opened this issue Sep 15, 2021 · 12 comments
Open

Allow referencing individual fields of a 1password item #69

lhriley opened this issue Sep 15, 2021 · 12 comments
Labels
tracked Issue is tracked in 1Password's internal ticketing system as well.

Comments

@lhriley
Copy link

lhriley commented Sep 15, 2021

Summary

When writing a OnePasswordItem definition, it would be helpful to reference individual fields of a 1password item rather than the entire item as a whole.

Use cases

For example, consider the setting of certain environment variables across several applications where may have different names, but require the same value.

App 1:

APP1_MY_VAR="foo-bar-baz"

App 2:

APP2_MY_VAR="foo-bar-baz"

Proposed solution

Create a new OnePassword kind (or modify the existing kind: OnePasswordItem) to allow referencing individual fields:

apiVersion: onepassword.com/v1
kind: OnePasswordFields
metadata:
  name: <item_name> #this name will also be used for naming the generated kubernetes secret
spec:
  itemFields:
    <k8s secret key name>: "vaults/<vault_id_or_title>/items/<item_id_or_title>/fields/<field>" 
    APP1_MY_VAR: "vaults/<vault_id_or_title>/items/<item_id_or_title>/fields/<field>" 
    APP2_MY_VAR: "vaults/<vault_id_or_title>/items/<item_id_or_title>/fields/<field>"

For example:

apiVersion: onepassword.com/v1
kind: OnePasswordFields
metadata:
  name: my-secret-app1
spec:
  itemFields:
    APP1_MY_VAR: "vaults/myVault/items/myItem/fields/token"
apiVersion: onepassword.com/v1
kind: OnePasswordFields
metadata:
  name: my-secret-app2
spec:
  itemFields:
    APP2_MY_VAR: "vaults/myVault/items/myItem/fields/token"

would produce the following secrets:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret-app1
  namespace: default
type: Opaque
data:
  APP1_MY_VAR: "foo-bar-baz"
apiVersion: v1
kind: Secret
metadata:
  name: my-secret-app2
  namespace: default
type: Opaque
data:
  APP2_MY_VAR: "foo-bar-baz"

Is there a workaround to accomplish this today?

Not using the onepassword-operator that I'm aware of. You could create multiple secrets from multiple vault items, and then individually reference the secrets created by the operator in each deployment, etc. This would create significant extra code, and be difficult to maintain.

References & Prior Work

None that I'm specifically aware of. This issue is similar, but appears to target mounting multiple items within a single k8s secret: #59

@florisvdg
Copy link
Member

Thanks for your suggestion. We're actually working on a way now that lets you map 1Password item fields to environment variables, so stay tuned!

@Nexus2k
Copy link

Nexus2k commented Mar 28, 2022

Any ETA on this?

@edif2008 edif2008 added the tracked Issue is tracked in 1Password's internal ticketing system as well. label May 30, 2022
@franklinkim
Copy link

+1

@Hobbit44
Copy link

@florisvdg Do you know if this is still in the roadmap? It seems to be almost a conflict between the 1password client's always showing of the username and password fields and being unable to remap them to other names.

My use case is that i have a username and password for ceph and the ceph helm chart expects the secret to be as userID and userKey.

@fw8
Copy link

fw8 commented Feb 15, 2024

+1

@Hobbit44
Copy link

I just want to highlight that if you want this to be viable against other products this is a nessecary feature. Currently it puts you behind provides such as csi-secrets-store-provider-aws, External Secrets and even Hasicorp vault. They all have this in some way or another.

@bdsoha
Copy link
Contributor

bdsoha commented May 3, 2024

+1

@dannysauer
Copy link

I've been trying to avoid writing a filtering secret sync operator for weeks hoping I'd stumble across a solution for this problem, but still nothing. The injector allows me to pick out arbitrary items, but requires full-access 1password credentials for each consuming pod. The operator fixes the credential issue, but replaces that problem with making me awkwardly structure 1password entries with duplicated data. 😅 How can I help with a hybrid solution? ;)

@stayanti
Copy link

stayanti commented Jun 6, 2024

Not being able to control the key of the secret is a showstopper here as well.

@bdsoha
Copy link
Contributor

bdsoha commented Jun 6, 2024

I have integrated external-secrets to work with 1password-connect in order to bridge this gap:

Example

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: minio
spec:
  secretStoreRef:
    kind: ClusterSecretStore
    name: onepassword
  refreshInterval: 500h
  target:
    deletionPolicy: Delete
  data:
    - secretKey: MINIO_ROOT_USER
      remoteRef:
        key: aws:minio
        property: access key
    - secretKey: MINIO_ROOT_PASSWORD
      remoteRef:
        key: aws:minio
        property: secret key

@stayanti
Copy link

stayanti commented Jun 6, 2024

Tnx, got a working solution, Adding a label to the onepassword item solved it for me. That way i can control the key of the secret

@Hobbit44
Copy link

@stayanti Have you got an example of how you fixed it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tracked Issue is tracked in 1Password's internal ticketing system as well.
Projects
None yet
Development

No branches or pull requests

10 participants