Support custom field-to-Secret key mapping for OnePasswordItem

[mhlgio]

Summary

Support custom field-to-Kubernetes-Secret key mapping for OnePasswordItem.

Today, the operator appears to create Secret data keys directly from 1Password item field names. This is awkward for integrations that require exact Kubernetes Secret key names.

Use cases

I’m using the 1Password Kubernetes Operator to manage Argo CD repository credentials.

Argo CD expects repository Secrets with specific data keys, for example:

type: git
url: <repo url>
sshPrivateKey: <private key>

When using a 1Password SSH key item, the generated Kubernetes Secret has fields like:

public-key
fingerprint
key-type
private-key

Argo CD does not know that private-key should be used as sshPrivateKey, so the generated Secret is not directly usable as an Argo CD repository Secret.

This issue also applies to other tools that expect fixed Secret schemas, camelCase keys, or application-specific key names.

Proposed solution

Add optional field mapping to OnePasswordItem, for example:

apiVersion: onepassword.com/v1
kind: OnePasswordItem
metadata:
  name: argocd-repo-infra
spec:
  itemPath: vaults/homelab/items/ArgoCD infra
  fields:
    - itemField: private-key
      secretKey: sshPrivateKey
    - itemField: url
      secretKey: url
    - itemField: type
      secretKey: type

Alternatively, a map-shaped syntax would also work:

spec:
  mappings:
    sshPrivateKey: private-key
    url: url
    type: type

The main goal is to let users keep 1Password item fields human-friendly while producing Kubernetes Secrets with application-specific keys.

Is there a workaround to accomplish this today?

The current workaround is to reshape the 1Password item itself so its field names match the consuming application’s expected Secret keys, or introduce another controller/tool to transform the generated Secret.

Both approaches are clunky:

• The 1Password item becomes tightly coupled to one Kubernetes consumer.
• Some apps require exact camelCase keys, like sshPrivateKey.
• It is unclear whether every desired Secret key can be represented reliably as a 1Password field name.
• Adding another Secret transformation layer reduces the simplicity of using the operator.

References & Prior Work

• Argo CD declarative repository Secret docs: https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#repositories
• Kubernetes Secret data keys: https://kubernetes.io/docs/concepts/configuration/secret/