-
Notifications
You must be signed in to change notification settings - Fork 107
Agenix integration #279
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
Agenix integration #279
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,18 +1,110 @@ | ||
| # Secrets | ||
| Secrets are managed using [git-crypt][git-crypt] so you can keep your flake in | ||
| a public repository like GitHub without exposing your password or other | ||
| sensitive data. | ||
| Secrets are managed using [git-crypt][git-crypt] and [agenix][agenix] | ||
| so you can keep your flake in a public repository like GitHub without | ||
| exposing your password or other sensitive data. | ||
|
|
||
| By default, everything in the secrets folder is automatically encrypted. Just | ||
| be sure to run `git-crypt init` before putting anything in here. | ||
|
|
||
| ## Agenix | ||
| Currently, there is [no mechanism][secrets-issue] in nix itself to deploy secrets | ||
| within the nix store because it is world-readable. | ||
|
|
||
| Most NixOS modules have the ability to set options to files in the system, outside | ||
| the nix store, that contain sensitive information. You can use [agenix][agenix] | ||
| to easily setup those secret files declaratively. | ||
|
|
||
| [agenix][agenix] encrypts secrets and stores them as .age files in your repository. | ||
| Age files are encrypted with multiple ssh public keys, so any host or user with a | ||
| matching ssh private key can read the data. The [age module][age module] will add those | ||
| encrypted files to the nix store and decrypt them on activation to `/run/secrets`. | ||
|
|
||
| ### Setup | ||
| All hosts must have openssh enabled, this is done by default in the core profile. | ||
|
|
||
| You need to populate your `secrets/secrets.nix` with the proper ssh public keys. | ||
| Be extra careful to make sure you only add public keys, you should never share a | ||
| private key!! | ||
|
|
||
| secrets/secrets.nix: | ||
| ```nix | ||
| let | ||
| system = "<system ssh key>"; | ||
| user = "<user ssh key>"; | ||
| allKeys = [ system user ]; | ||
| in | ||
| ``` | ||
|
|
||
| On most systems, you can get your systems ssh public key from `/etc/ssh/ssh_host_ed25519_key.pub`. If | ||
| this file doesn't exist you likely need to enable openssh and rebuild your system. | ||
|
|
||
| Your users ssh public key is probably stored in `~/.ssh/id_ed25519.pub` or | ||
| `~/.ssh/id_rsa.pub`. If you haven't generated a ssh key yet, be sure do so: | ||
| ```sh | ||
| ssh-keygen -t ed25519 | ||
| ``` | ||
|
|
||
| > ##### _Note:_ | ||
| > The underlying tool used by agenix, rage, doesn't work well with password protected | ||
| > ssh keys. So if you have lots of secrets you might have to type in your password many | ||
| > times. | ||
|
|
||
|
|
||
| ### Secrets | ||
| You will need the `agenix` command to create secrets. DevOS conveniently provides that | ||
| in the devShell, so just run `nix develop` whenever you want to edit secrets. Make sure | ||
| to always run `agenix` while in the `secrets/` folder, so it can pick up your `secrets.nix`. | ||
|
|
||
| To create secrets, simply add lines to your `secrets/secrets.nix`: | ||
| ``` | ||
| let | ||
| ... | ||
| allKeys = [ system user ]; | ||
| in | ||
| { | ||
| "secret.age".publicKeys = allKeys; | ||
| } | ||
| ``` | ||
| That would tell agenix to create a `secret.age` file that is encrypted with the `system` | ||
| and `user` ssh public key. | ||
|
|
||
| Then go into the `secrets` folder and run: | ||
| ```sh | ||
| agenix -e secret.age | ||
| ``` | ||
| This will create the `secret.age`, if it doesn't already exist, and allow you to edit it. | ||
|
|
||
| If you ever change the `publicKeys` entry of any secret make sure to rekey the secrets: | ||
| ```sh | ||
| agenix --rekey | ||
| ``` | ||
|
|
||
| ### Usage | ||
| Once you have your secret file encrypted and ready to use, you can utilize the [age module][age module] | ||
| to ensure that your secrets end up in `/run/secrets`. | ||
|
|
||
| In any profile that uses a NixOS module that requires a secret you can enable a particular secret like so: | ||
|
|
||
| ```nix | ||
| { self, ... }: | ||
| { | ||
| age.secrets.mysecret.file = "${self}/secrets/mysecret.age"; | ||
| } | ||
| ``` | ||
|
|
||
|
|
||
| Then you can just pass the path `/run/secrets/mysecret` to the module. | ||
|
|
||
| You can make use of the many options provided by the age module to customize where and how | ||
| secrets get decrypted. You can learn about them by looking at the | ||
| [age module][age module]. | ||
|
|
||
|
|
||
| > ##### _Note:_ | ||
| > Currently, there is [no mechanism][secrets-issue] in nix to deploy secrets | ||
| > within the nix/store so, if they end up in the nix/store after deployment, they | ||
| > will be world readable on that machine. | ||
| > | ||
| > The author of devos intends to implement a workaround for this situation in | ||
| > the near future, but for the time being, simple be aware of this. | ||
| > You can take a look at the [agenix repository][agenix] for more information | ||
| > about the tool. | ||
|
|
||
| [git-crypt]: https://github.com/AGWA/git-crypt | ||
| [agenix]: https://github.com/ryantm/agenix | ||
| [age module]: https://github.com/ryantm/agenix/blob/master/modules/age.nix | ||
| [secrets-issue]: https://github.com/NixOS/nix/issues/8 |
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,6 +8,7 @@ channels: final: prev: { | |
| discord | ||
| element-desktop | ||
| manix | ||
| rage | ||
| nixpkgs-fmt | ||
| qutebrowser | ||
| signal-desktop | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -143,6 +143,12 @@ in | |
| ''; | ||
| }; | ||
|
|
||
| # For rage encryption, all hosts need a ssh key pair | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this necessary? Looking at
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, Sorry I overlooked the man page. Just ignore this comment.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would be nice if it was possible to generate these files without enabling the openssh daemon. It would require decoupling the key generation parts from the daemon parts of the nixos sshd module.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about if I write a bash to generate these files by executing remote ssh. It would be an alternative choice for generating keys.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not a bad idea, but it doesn't feel declarative. I think this seems to be the best solution for now. We could alternatively generate the hostKeys ourself, but that would conflict with the ssh module.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For future reference, perhaps we could just make a more minimal module that generates the keys, but doesn't enable ssh.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Optimally we could contribute changes to the upstream ssh module to separate host key generation from the daemon itself. |
||
| services.openssh = { | ||
| enable = true; | ||
| openFirewall = lib.mkDefault false; | ||
| }; | ||
|
|
||
| services.earlyoom.enable = true; | ||
|
|
||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,4 @@ | ||
| * filter=git-crypt diff=git-crypt | ||
| .gitattributes !filter !diff | ||
| secrets.nix !filter !diff | ||
| README.md !filter !diff | ||
|
Comment on lines
1
to
4
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We should probably leave it in the template for backwards compatibility - users might be storing secrets with the assumption that they are going to be encrypted. But I would be in favor of removing it at some point. Cool addition if you drop git-crypt:
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm also in favor of dropping it.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm late to the party, but it would be good to drop as it actually enourages bad secrets management (putting secrets into Nix store). This was really more of a move of desparation on my part than an actual well thought out secrets strategy.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. definitely agree, I'm just more worried about someone not realizing git-crypt usage in secrets is dropped and committing their secrets to a public repo. Which is arguably worse. |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| let | ||
| # set ssh public keys here for your system and user | ||
| system = ""; | ||
| user = ""; | ||
| allKeys = [ system user ]; | ||
| in | ||
| { | ||
| "secret.age".publicKeys = allKeys; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
off topic:
We might want to push for an update to latest release asap: https://github.com/str4d/rage/releases
Because:
And I see how people want to use https://github.com/str4d/age-plugin-yubikey to seamlessly decrypt with their security key