About managing multiple recipients

[cipriancraciun]

At the moment, if I understand correctly, the tool is able to encrypt a YAML file for a single recipient, whose private key should be in the possession of everyone interested of decrypting the file.

However, I wonder if you've taken into account the following use-cases which involve multiple recipients:

• (following the best-practices), each team member should have it's own private / public key pair, and when a new team member is added, some files should be re-encrypted to include him;
• say someone is leaving the team, now the question is which credentials does he have access to?

Unless the scope of the project is to be as simple as possible -- which is a valid desire -- I think some thought should be given to how to manage these multiple recipients:

• at the moment perhaps the CLI can be enhanced to support multiple recipient arguments, but this easily becomes unmaintainable; (everyone must remember to use the same recipients;)
• perhaps have a file (one per repository or something akin to .gitignore) that states which file should be encrypted to which recipients;
• perhaps amend the YAML (either through the front-matter feature (I think it's supported by YAML?), or perhaps through some "meta keys") format to allow specifying which recipients to use;

[glehmann]

The tool already supports multiple recipients, and the recipients are listed in each encrypted value.

Let's create 2 identities, Bob and Alice

$ yage keygen -o bob.key -p bob.pub
Public key: age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3
$ yage keygen -o alice.key -p alice.pub
Public key: age16wa42pta47k4fjl9yn2edfj0pvp58pu3stmkt2st027er4k6uvxsr4mzav

Then encrypt a yaml file for both Alice and Bob:

$ cat foo.yaml 
foo: aaaaa
bar: 42
$ yage encrypt -R bob.pub -R alice.pub -i foo.yaml
$ cat foo.yaml 
foo: yage[YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSB3M0QzZjBmZmdNNVkxNkZXY0JBUGFVN21kanFlRnl4QlZUeU1EN1d4bkVvCkJZc3lqWndYY055VVpyZzgrTFZaSnlHZlM5VHdiTTBrQXE1ckRUYmdrclUKLT4gWDI1NTE5IEdFY2JhajRPRmwxYnB4a3VsOXltZlV3VkpTelM5QUtsaVU0NEF3SE5mQUEKTUtwQkFldkVFblJtdGhKQW1hV0srUXdOUXR5N0ZoWUFIUUFVYkJuZHQ5dwotPiAlQydSZi1ncmVhc2UgL2VKNEJfSywgXTovJGIkMSBJMWVEX3oqOCBbcykKVTlFeXpBRUJuazU3MGJzN3VpUGZ5TVFtM2IrWWRGZ1BtZk5aCi0tLSBvT0Joa2xOM2hpZjQzbzRtYWkreW1JUHBwSzlRMElVVU5jcklobUFpSkpnCi7J6bApB15AS1rN9luYrX4Ah+QWHdK8GMswluUxiU4E4iUgaZKa|r:age16wa42pta47k4fjl9yn2edfj0pvp58pu3stmkt2st027er4k6uvxsr4mzav,age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3]
bar: yage[YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSAza01ES0ZqaXh2MXJaVWpldWoxK1Z0M0NNUzVaL29JU0hHUFlHQTJ5czJFCjVjWkVtdy9Oc213Zlg1VDRMdXpPY3Z4YkU5M3FCTllrNFEvU2RMazM2UHMKLT4gWDI1NTE5IDhSRHhRMHcvVVh5SFNVV0lYQU9TdkFFamxIL2F0cVRaTnZwSVhxWm5vMzgKUW5OMm82U0JoTUNldGhOY1RJdElUdldTZ3pNcWtwRktDZjNOeXBsaXJrWQotPiA/MXAtZ3JlYXNlIF1Hc0N8I2NUClVwMnNMT2lKZXNNQ0Z2dTRsdTV4empEWFZmaU8xbDNwa3orNXlRdUsrZW8rbW5YdUhIVmZsc3N0UVI1aThzZmwKSVVCOE13ZDdRS0EKLS0tIHAveXg5QWQ2WUlzZFUxZzIxbFN1VGFDQkxwbFdobStlVW9BVEFJVkI2VGcKdUp6AGVRGFM6XclyvCHGmW6NDL4iKMI+nx38KWGahzDAfi7tZg==|r:age16wa42pta47k4fjl9yn2edfj0pvp58pu3stmkt2st027er4k6uvxsr4mzav,age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3]

There is a command to list the recipients of an encrypted file:

$ yage recipients foo.yaml 
foo.yaml: age16wa42pta47k4fjl9yn2edfj0pvp58pu3stmkt2st027er4k6uvxsr4mzav
foo.yaml: age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3

and both Bob and Alice are able to decrypt the file

$ yage decrypt -K bob.key foo.yaml 
foo: aaaaa
bar: 42
$ yage decrypt -K alice.key foo.yaml
foo: aaaaa
bar: 42

yage also supports re-encrypting the file for new or removed recipients. Here we add Helen as a new recipient, remove Alice, and use Bob's private key to decrypt the file before re-encrypting it with the new recipients:

$ yage keygen -o helen.key -p helen.pub
Public key: age14g73g384ds46uudqhflqa8xne3cz73l4yu2d56k4u4nxe3znd97s00g7pm
$ yage re-encrypt -K bob.key --keep-recipients -D alice.pub -R helen.pub -i foo.yaml
$ yage recipients foo.yaml
foo.yaml: age14g73g384ds46uudqhflqa8xne3cz73l4yu2d56k4u4nxe3znd97s00g7pm
foo.yaml: age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3

I may be missing something, but I think your use case is quite well covered already :-)

Note that re-encrypting the values is not enough when someone is leaving though — Alice still has access to the older versions, so the secrets should be rotated.

Thanks for your interest in yage!

[cipriancraciun]

Indeed, it appears yage does cover the use-case I was speaking about.

However, reading the README doesn't convey this information (I didn't have the time to try yage myself to see if it actually did support it).

Perhaps it would be a good idea to copy some of these snippets or at least a summary to the README.

[cipriancraciun]

Note that re-encrypting the values is not enough when someone is leaving though — Alice still has access to the older versions, so the secrets should be rotated.

Indeed, the secrets previously accessible to the leaving employee should be rotated.

Does yage help me in identifying which exactly are the keys / values that were previously accessible with "Alice"'s key? At the moment yage lists the public keys that can read some values from a YAML file, but could it list exactly which keys?

---

There is also the issue of the Git history... One should also verify all the previous versions of the YAML file to see which past secrets (that haven't been rotated yet) were accessible in the past.

But this isn't an issue that yage can directly implement. It's just something that would be worth mentioning is the security analysis.

[glehmann]

However, reading the README doesn't convey this information (I didn't have the time to try yage myself to see if it actually did support it).

Perhaps it would be a good idea to copy some of these snippets or at least a summary to the README.

Indeed, I'll add a section about multi-recipients 👍

[glehmann]

Does yage help me in identifying which exactly are the keys / values that were previously accessible with "Alice"'s key? At the moment yage lists the public keys that can read some values from a YAML file, but could it list exactly which keys?

There is nothing specific to search for some files that may have been encrypted and visible by a user, but yage is made to integrate easily with the usual unix command line tools. Combining yage recipients, which lists all the recipients for a yaml file, with some of those tools can get the job done quite easily:

$ find . -name '*.yaml' | xargs yage recipients | grep age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3
./foo.yaml: age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3

or if you are in a git repository and only want to check the files already added to the repository:

$ git ls-files '*.yaml' | xargs yage recipients | grep age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3
./foo.yaml: age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3

If you don't mind relying on the internal yage format, a simple grep or rg with the public key of the user can give you the information you want, because the recipients are listed in each encrypted values — see the |r:… section at the end of the value.

$ rg -g '*.yaml' -l age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3
foo.yaml
$ grep -rl age1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3 .
./foo.yaml
./bob.pub

There is also the issue of the Git history... One should also verify all the previous versions of the YAML file to see which past secrets (that haven't been rotated yet) were accessible in the past.

git provides some tools to search for a specific string — we can you that to search for the occurrence of the public key of the person who is leaving:

$ git log --stat -Sage1gx7xge9kmhkxl557ypgl8hj89rvvkk6h724dz80axlxplzc0laqsyhg8c3

that's not as easy as working with the files in the current directory, but I'm not sure what we could do to make it more practical.
Do you have an idea of what yage could do to help with that use case?

[glehmann]

Up to now I made the assumption that all the file content should be readable by the same set of recipients. There is a list per encrypted value, but it's only purpose is to:

• store the recipient list without introducing any new field in the yaml file
• being able to detect when a file contains encrypted values with inconsistent recipients
  I'm not sure I want to change that assumption

[glehmann]

I suppose that you propose to list accessible keys in order because you don't want all the encrypted values to be accessible by the same recipients set — please correct me if I'm wrong

[cipriancraciun]

Given the way I understand yage currently works, one can have mixed recipients for different key / value pairs in the same YAML. Thus, at least theoretically, it is possible (perhaps via manual copy-paste after encryption) to have multiple different recipients in the same YAML file.

Therefore, I thought it would be nice to see who has access to what in a given YAML file.

---

Perhaps I'm complicating stuff too much, but given the current format one can achieve such configurations -- for example I would prefer to have a large single file with everything in it (perhaps per environment) because it's easier to manage -- thus given the possibility some users might create such mixed recipient files.

[glehmann]

I understand that it could be useful, but I think that selecting exactly who is the recipient of each individual value would complicate quite a lot the yage interface.

[glehmann]

When I write that I also think to SOPS who is enforcing to split our secrets in many small files — that's why they can have a global MAC, and that's something that is not working well for me — and I have the feeling to do the same here.
Finding the balance between the feature set and the tool complexity is not an easy task!