Allow to encrypt specific nodes in a file with specific keys (muliple matching creation_rules)
c33s opened this issue · 3 comments
it would be really awesome to be able to encrypt parts/specific nodes with different keys. as far as i have seen it is currently only possible to encrypt a whole file with a specific set of keys.
sometimes it would be really handy to be able to encrypt only specific nodes/keys value pairs with a specific set of keys.
maybe the creation_rules
can do that. having a .sops.yaml
file with multiple creation_rules
will currently only match the first match of path_regex
but it maybe it can continue (for example with a flag set in the creation_rule like continue
or the oposite stop_propagation
) to the next rule so we could have something like this:
creation_rules:
- encrypted_regex: 'docker_registry_password'
path_regex: .*/dev/.*\.yaml$
age: 'A'
continue: true
- encrypted_regex: '.' # prevent encryption of comments https://github.com/mozilla/sops/issues/921
path_regex: .*/dev/.*\.yaml$
age: 'A,B'
propagation_stop: true
# catch-all
- encrypted_regex: '.' # prevent encryption of comments https://github.com/mozilla/sops/issues/921
age: 'C'
for yaml files which are in the dev
folder the docker_registry_password
will be encrypted with key A
. if no continue would be present, it would be the only node which is encrypted and the rest is unencrypted. having the continue in place leads the processing the next rule which also matches the path_regex
. all other nodes are now encrypted with key A and B. with propergation_stop the processing stops after matching this rule.
this are just thoughts, i don't know if it is possible from the current code design. still it would be really awesome.
This would require a large redesign of the code, including a backwards-compatibility breaking redesign of the metadata stored.
The how to configure this (via different creation rules) is likely the least complicated part of impementing this.
what about adding the info of "it is currently not possible to encrypt different nodes with different keys"? this could save some time for others in the future.
@c33s feel free to create a PR to suggest where to place that documentation.