Inquiry about security best practices using NixOps

Help
1

Hello,

I’m currently developing an application making use of NixOps to automatically orchestrate multiple small programs/services.

I’ve asked myself how to properly harden the servers and what would be the best way to use API keys and other secrets.

Currently, each service I run has a unique unix account with the least amount of privileges it can survive with (most are just users.users.<name> = {};.) and connects to postgresql through pgbouncer using peer authentication, connecting to roles with minimal privileges.
Is it something I can rely on ?

Will Fancher’s “Secure, Declarative Key Management with NixOps, Pass, and nix-plugins” has been a great help to start with my second question, it lets me share secrets between developers, but what’s the best way to inject secrets into applications? I’ve had this preconception that using environment variables would be safe, but I found out that /proc/pid/environ just displays those in plaintext.

I’m very much aware that most of infosec failures happen on the human-level, which is why I’m trying to automate as much as possible, NixOps seems like just the tool for the job.

Thanks!

1 Like
2

Hi.

NixOps supports “keys” which, despite the name, can be other kinds of secrets. By default these keys are stored in a temporary location, but you can choose the path. I store them in /root or /home/user and give them limited permissions. You can refer to the deployment.keys.<KEYNAME>.path in your NixOS/nixops expressions without the secrets being placed in the nix store.

Most applications support reading from files to inject secrets.

Ryan

3

This is only readable for the owner of the process and root though, so it’s not so much of an issue.

1 Like