manage secrets properly #16

New issue

Open

opened 2024-05-25 00:09:50 +02:00 by taeer · 1 comment

taeer commented

2024-05-25 00:09:50 +02:00

Collaborator

I have to think carefully about how to manage secrets here. My go-to has typically been agenix, which is quite popular and integrates well with NixOS. I have not carefully evaluated its security profile though.

Options:

agenix
- manage everything through the NixOS configuration
- different machines can access different secrets
- puts the secrets (encrypted) in the nix store
sops-nix
- similar to agenix
- less nice to work with in my experience
using some deployment tool to manage secrets
- adds a layer of complexity in my opinion
- state adds the likelihood of things getting out of sync. reduces reproducibility
- if there are other things we need to manage statefully, this becomes less of a concern.

I have to think carefully about how to manage secrets here. My go-to has typically been [agenix](https://github.com/ryantm/agenix), which is quite popular and integrates well with NixOS. I have not carefully evaluated its security profile though. Options: - agenix - manage everything through the NixOS configuration - different machines can access different secrets - puts the secrets (encrypted) in the nix store - sops-nix - similar to agenix - less nice to work with in my experience - using some deployment tool to manage secrets - adds a layer of complexity in my opinion - state adds the likelihood of things getting out of sync. reduces reproducibility - if there are other things we need to manage statefully, this becomes less of a concern.

taeer commented

2024-05-30 05:25:14 +02:00

Author

Collaborator

I had a thought about how to go about this. I'm not totally sold on this yet, it's just the first thing to come to mind.

We add the submodule secrets.<name> which has the common options needed to define how the secret will be used: owner, group, and the output path. When you want to use a secret you set

{
  secrets.foo.owner = "blah";
  secrets.foo.group = "blah";

  services.blah.options.secret_file = secrets.foo.path;
}

Now the different secrets-providers can provide whatever options they want

  # uses an encrypted source file
  secretsnix.foo.source = ./foo.secret;
  # uploads the secrets at deploy time
  deploySecrets = [ "bar" "baz" ];

as long as they take into account the owner and group, and set the output path, they can work however they want, and the user gets a consistent interface, so they can even migrate secret systems fairly painlessly.

Robert had a thought about how to structure this when we met the other day. Which is to have a unified nixos module that Expressed the Need for a secret, without defining where that secret comes from. Then different secret-providing systems can plug into that and provide the secret. --- I had a thought about how to go about this. I'm not totally sold on this yet, it's just the first thing to come to mind. We add the submodule `secrets.<name>` which has the common options needed to define how the secret will be *used*: owner, group, and the **output** path. When you want to use a secret you set ```nix { secrets.foo.owner = "blah"; secrets.foo.group = "blah"; services.blah.options.secret_file = secrets.foo.path; } ``` Now the different secrets-providers can provide whatever options they want ``` # uses an encrypted source file secretsnix.foo.source = ./foo.secret; # uploads the secrets at deploy time deploySecrets = [ "bar" "baz" ]; ``` as long as they take into account the owner and group, and set the output path, they can work however they want, and the user gets a consistent interface, so they can even migrate secret systems fairly painlessly.

This repo is archived. You cannot comment on issues.

No labels

No milestone

No project

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Fediversity/simple-nixos-fediverse#16

No description provided.