Support for multi-line secrets

[jondkelley]

Summary

We have services that require specifically formatted TLS certificates in order to decode them.

This specific formatting requires newline characters, as a single-line input mode does not exist for the libraries in use for decoding keys.

Use cases

• Support for DER, PEM, RSA, DSA, PGP keys
• Multi-line secret configurations

Proposed solution

Should potentially add a flag to the CRD that tells the operator how to handle newlines (UNIX/WINDOWS?) in addition to which character should be converted in the newline character syntax.

You could add:

metadata.insertNewline=0x0a
metadata.findNewline=0x0a

(Where if you want to make a Windows compliant CR/LF you could do metadata.insertNewline=0x0d0x0a

Is there a workaround to accomplish this today?

Unknown

References & Prior Work

[bygui86]

@jillianwilson any ETA for this?

[Loki-Afro]

another use case: htpasswd with multiple users, those have to be separated by new lines

[Marton6]

A possible workaround for this issue could be to use file fields or Document items to store multi-line secrets. Files stored in 1Password can contain arbitrary data, including multi-line strings.

Support for loading data from file fields into Kubernetes secrets has just been added in v1.3.0

[Marton6]

Closing as the issue is addressed by file support. Please reopen it if file support alone does not cover your use cases.

[robcxyz]

@Marton6 - Can this be reopened considering the community response?

[viraptor]

yes, I would like to reopen @Marton6 , it does not cover my use case where the secret should be copy/pasted and is not a file

[Marton6]

@robcxyz, @viraptor Yes, of course I'll reopen the issue.

I'm trying to understand what the actual use case / feature request is here.

Is it the following?

A way to store multiline secrets in 1Password such that they can be copy-pased with a single click from the 1Password desktop app UI.

And are there any other UX problems with using attached file fields? File fields and documents should work exactly like multiline secrets in the developer tools (including the CLI and the Kubernetes Operator).

[robcxyz]

@Marton6 - Thanks for asking... So for me I ran into this two places, the first being certificates like the original issue was opened over. Many people would prefer copy and pasting the cert in over saving the cert to file before loading it into 1p. A nice workaround could be an easier way to copy the cert in but have it saved in 1p as a file so the user doesn't actually have to make a file out of the secret.

The second was storing yaml blobs as is the case when you are trying to store random data in a k8s secret. One workaround was using a database secret but very limiting when there are many keys. Also the terraform provider doesn't allow setting database random keys but I think does support getting random database keys but iirc it was somewhat hacky. Again a potential solution could be being able to paste something in and have it saved as a file but then you can't easily just edit the secret.

IMO - while the file type secrets technically are a solution, everyone new to the tool will hit this constraint and ask the same question, why can't I put multi-line strings in a secret and hence all the reactions...

Appreciate you following up on this.

[johnwiseheart]

In my use-case, I'd like to use 1password to store a certificate, and then use that certificate via the 1password CLI. However, when set as just a text type (and I assume the same for file types) rather than a password type, the private certificate is not masked the same way that passwords are. Ideally I'd like a multiline secret field which would allow me to store the certificate but keep the masking, both in the 1password UI as well as the CLI.

[viraptor]

For me the use case was both YAML fragments and encrypted messages in the ----- BEGIN ... form. (where I'm expected to paste them rather than use them as files)

[grzegorzkrukowski]

Similar use-case for me - I want to load private using 1password CLI:

- name: Load common secrets
   uses: 1password/load-secrets-action@v2
      env:
        SSH_KEY: "op://application/private-key/key"
- name: Set up SSH agent
   uses: webfactory/ssh-agent@v0.7.0
   with:
      ssh-private-key: "${{ env.SSH_KEY }}"

Currently, it says "invalid format" due to how the variables are loaded and I am forced to use GitHub Secrets instead.

[koreyGambill]

Another use case - rabbitmq operator configuration requires a multiline string like this
default_user.conf=

default_user = <some user>
default_pass = <some pass>

which is not possible with the password field. The file field does work, but it's difficult to work with. I would rather not save the credentials to my computer, upload the document, then worry about deleting it. Same for when I need to reference the credentials, it's odd to have to download the file to my computer and open it in an editor to find the credentials, and once again worry about deleting them.

I can technically use the text field type, but that means if I accidentally flip to the rabbit password on a screenshare I leak the credentials. It would make the most sense to use the password field if it could contain newlines.