RFC: agenix-rs tool

[cole-h]

Over the past few weeks, I've been working on a replacement for the shell script agenix tool, written in Rust. I've published it at https://github.com/cole-h/agenix-rs/.

I really like how sops-nix has the sops tool to edit binaries and then encrypt them to the proper recipients based on path globs specified in a config file, and I really dislike how the agenix script required a secrets.nix file for the identities.

I'm hoping for any and all feedback on it, and in the future it would be nice to replace the agenix shell script with agenix-rs.

[ryantm]

Cool, I'll have to take a closer look soon.

The reason I chose to use Nix instead of Yaml (like sops), is that I wanted to be able to program the mapping of keys to secrets a bit. For example, I have a list of server admins, and I'd like to be able to give them access to a bunch of secrets without copying the list of admins to every secret.

[ryantm]

Or maybe a better example is, I have some monit certificate PEM file that is a secret that I want to distribute to all my servers, so, I'd like to maintain a list of servers, and not have to remember to update the the monit secret's list every time.

[ryantm]

Is your concern with the secrets.nix approach that you have to list every secret?

[cole-h]

Would a [groups] table work for you? Something like:

[identities]
admin1 = "ssh-ed25519 ...."
admin2 = "ssh-ed25519 ...."

[groups]
machine1Admins = [ "admin1", "admin2" ]

[[paths]]
glob = "monit"
groups = [ "machine1Admins" ]

That would be pretty easy to implement.

[ryantm]

Would a [groups] table work for you?

Yep!

Another reason I was going toward the .nix approach is because I have to keep a attrset of public keys in Nix too for NixOS configuration, but Nix can read TOML files, so that shouldn't matter.

[cole-h]

Is your concern with the secrets.nix approach that you have to list every secret?

That's one thing I didn't like about secrets.nix for sure. The other thing I didn't like about the agenix script was how secrets.nix was relative and not "autodetected" like sops does (and how agenix-rs does -- by ascending directories until it finds it, limited to a maximum of 100 directories). Minor things, really, but I'm more familiar with Rust than bash, so I decided to rewrite it rather than try to fix these things in bash :P

[cole-h]

cole-h/agenix-cli@79707b6 implements the desired groups functionality.

[ryantm]

@cole-h Do you already have nix expressions for integrating agenix-rs with the agenix repo? I'd like to try it out!

[cole-h]

I just pushed a flake.nix (as well as a default.nix and shell.nix via flake-compat), hope that works for you :)

[ryantm]

@cole-h I'm newly interested in this because I really want to fix #4 I tried it out some. It seems like it doesn't support rekeying all the paths at once. Is that right? If not, I'm up for trying to add that feature to learn more about the code.

[cole-h]

I believe that is correct. I'd be glad to accept a PR implementing that. Hopefully the code is clean / easy (enough) to read, but feel free to ask for help / pointers!

[kanashimia]

Note that on the other end with secrets.nix you can do a lot more interesting stuff, like fetching keys from a key server, take a look: my repo
Albeit above example isn't that useful for me tbh.

[ryantm]

@kanashimia Interesting. I think this approach is making you vulnerable to rekeying your secrets based on GitHub (or someone infiltrating GitHub) adding additional public keys to that file.

With the rust version, you could achieve the same effect by writing a wrapper script that generates the TOML file on the fly.

[ryantm]

I just learned about https://github.com/yaxitech/ragenix from @veehaitch @vtuan10 . Would share your opinion about why you like using Nix expressions for specifying your secret rules?

[veehaitch]

Some considerations which come to my mind:

• We appreciate the clarity and explicitness of the secrets.nix schema.
• We like to keep our secrets close to the configuration it belongs to.
• It is also easy to reference/import common Nix files and to set the necessary option values for the agenix module.
• We have the flexibility of the Nix expression language.
• It was the natural choice to define and maintain our secrets using Nix expressions for our Nix(OS) configurations.

[n8henrie]

Is this still being considered? Certainly seems like it would have some advantages. If not should we close? @cole-h looks like last commit was about a year ago?

[cole-h]

I don't mind either way. I'll continue to use agenix-cli, and will gladly accept any PRs that come to my attention :)