Create an encryption/decryption selector

[andor-pierdelacabeza]

So, to help creating automatic tools and following diffs, there are parts of a yaml/json file that shouldn't be encrypted, and that cannot be done easily with encrypted/unencrypted_suffix.

My use case is Kubernetes yaml/json secrets definitions. Lets see an example:

apiVersion: v1
kind: Secret
metadata:
 namespace: staging
 name: web-secrets
type: Opaque
data:
 GOOGLE_CLIENT_ID: yadayadayada
 GOOGLE_CLIENT_SECRET: yadayadayada

Here, the only part that needs to be encrypted is the data section. Having metadata, type and the other sections unencrypted helps to follow changes, especially by people with no permission to encryption, and automatic tools.

Doing this with unencrypted_suffix is difficult, as I can only select one key.
Also, doing it with encrypted_suffix is difficult too, as, if I select the data suffix, I'll encrypt both data and metadata.

I can't alter the structure of this yaml, as it's inherent to Kubernetes, so it'd be great to have a feature that would allow me to select just one section of the yaml/json file, something like:

sops --encrypt --encryption-selector '.data' file.yml`

Extra:

• Unencryption selectors
• Multiple selectors

[autrilla]

I think Kubernetes is a big enough use case that it might be simpler to just have a Kubernetes-specific store ("format") as we do for plain YAML and JSON files. What you propose is more flexible, but it feels harder to implement to me.

[andor-pierdelacabeza]

It may fit another use cases, I don't know, lets see if anybody chips in 👍 :)

[stephenmoloney]

an alternative is to use bitnami sealed-secrets.

[andor-pierdelacabeza]

I've seen now there is an --encrypted-regex option.

So, using a command like:
sops --encrypt --gcp-kms [REDACTED] --encrypted-regex '^(data)$' secret.yml

Would result in:

apiVersion: v1                                                                                                                                        
kind: Secret
metadata:
    namespace: staging
    name: web-secrets
type: Opaque
data:
    GOOGLE_CLIENT_ID: ENC[AES256_GCM,data:PXm3rsZF5kXpsUaH,iv:BYR4vkrJlALqJk/FABREmwxn7dkXNNehtTZl9tyl2SE=,tag:ZleNE201N0ltPnmTiYC6ng==,type:str]
    GOOGLE_CLIENT_SECRET: ENC[AES256_GCM,data:eMRXNtoe3uy5OB5F,iv:/SVah//dRFxTGipkUo403UUsFWCoZ7cxLsETnh9IW84=,tag:BI57M2VMwEMJ4Wo+3WoS0g==,type:str]
sops:
[REDACTED]

And that seems to fit this use case I presented two years ago.

I feel like this issue is covered and may be closed. Do you agree with me, @autrilla ?

Thanks for your hard work :)

[autrilla]

Kind of. While your particular use case is resolved, other possible use cases the selector solution would have solved are not. That said, I'm going to close this, and if someone has a use case that would be covered by the selector solution but are not covered by regexes, they can let us know.