getsops
New `input_type` (and `output-type`?) parameter in config file
I've just discovered this project, and I'm amazed by the simplicity of usage and yet how yet powerful the sops CLI tool is! Congratulations!
My current use case for sops is to encrypt Kubernetes secrets in a git repository. So I created this configuration file:
# .sops.yaml
creation_rules:
- path_regex: ^.*secrets\.yaml(\.enc)?$
encrypted_regex: '^(data|stringData)$'
age: >-
<my-age-public-key>
which allows me to easily encrypt any secret.yaml file in the repository with this command:
sops -e secrets.yaml > secrets.yaml.enc
I specifically changed the output's file extension so that when I run a kubectl apply -f . in the folder, I don't have any issue with the unexpected fields in the encrypted file. This way, I can easily ignore all the secrets.yaml files in my repository and use them only when I want to apply secrets.
So when I want to decrypt a secret, I use this command:
sops --input-type yaml -d secrets.yaml.enc > secrets.yaml
This is fine, but I thought that since a creation_rule can target a specific file extension, it could make sense to add a property like input_type to it so that I don't have to manually set it every time I want to decrypt the file. So the proposed configuration could be something like:
# .sops.yaml
creation_rules:
- path_regex: ^.*secrets\.yaml(\.enc)?$
encrypted_regex: '^(data|stringData)$'
input_type: yaml # we force this input type for all files picked up by this rule
age: >-
<my-age-public-key>
As I said in my introduction, I'm very new to the project, and maybe I'm missing something here. But I thought that it could be a common use case and that it might be worth proposing.
Have a good one!
N.B.: in my .sops.yaml configuration, I set the path_regex to allow the extra extension for the encrypted file. I don't know if this is as expected or if it's just a workaround to issue #868.
Just to add on the above that following the proposition around the default output type when an input type is set (see #596), I was thinking that the output-type could also be added to a creation rule?
Although it could be different from the input type, I imagine that if the default behaviour was agreed upon for explicit CLI parameters, it could follow the same logic in the config. Or maybe we don't like defaults, which would be fine, just worth mentioning to the users :)
