Support secrets with sections containing same key names

[lhriley]

Summary

Support secrets where section headers delineate related sets of secrets that contain the same keys.

Use cases

For some use cases, a secret item may contain multiple sections that describe the same kinds of information (keys) with different values.

For example:

username: nosection
password: nosection

sectionA:
  username: foo
  password: foopass

sectionB:
  username: bar
  password: barpass

[...]

sectionZ:
  username: zed
  password: zedpass

Proposed solution

Create secrets based on the section name as a suffix.

For example:

mysecret -> no section key / values
mysecret-sectionA -> sectionA key / values
mysecret-sectionB -> sectionB key / values
[...]
mysecret-sectionZ -> sectionZ key / values

This should be gate-able via annotations on the OnePasswordItem such as:

operator.1password.io/secrets-from-sections: <bool>

The default behavior should be disabled as sections may not contain duplicate keys.

Alternatively, prefix the key name with the section name:

For example:

username: nosection
password: nosection
sectionA-username: foo
sectionA-password: foopass
sectionB-username: bar
sectionB-password: barpass
[...]
sectionZ-username: zed
sectionZ-password: zedpass

This should be gate-able via annotations on the OnePasswordItem such as:

operator.1password.io/sections-prefix-keys: <bool>

The default behavior should be disabled as sections may not contain duplicate keys.

Is there a workaround to accomplish this today?

1) Create separate onepassword secret items and OnePasswordItem for each corresponding section rather than keeping all secrets in a single item.

2) Uniquely name each key / value pair so they don't conflict.

Note that currently, for secrets containing sections with the same key names, the last matching key/value pair wins.

References & Prior Work

• This PR adds support for environment variables by keys in sections: https://github.com/1Password/onepassword-operator/pull/79

[edif2008]

Hey @lhriley,

This is a known limitation of the current version of the Operator. Your use case is an interesting one and I can see other folks benefitting from this enhancement.

Do you feel that the release of the injector would solve your use case? or would you still prefer to have this supported in the operator as well?

[krokofant]

The op cli can target a section by specifying like this label=AnotherSection.username so would it be possible to have the same kind of syntax for this? Just use a [section.]{key}

[TheAnachronism]

Are there any updates to this?

[LoicFerrot]

We just hit the same limitation in our team...