-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New input_type
(and output-type
?) parameter in config file
#982
Comments
input_type
parameter in config fileinput_type
(and output-type
?) parameter in config file
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 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 :) |
Duplicate of #813 |
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: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 thesecrets.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 likeinput_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: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 thepath_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.The text was updated successfully, but these errors were encountered: