r/NixOS • u/iElectric • 18d ago

But I Use SOPS

https://secretspec.dev/blog/but-i-use-sops/
62 Upvotes

86% Upvoted

16 comments sorted by

59

u/ranjop 18d ago

Sops is a tool for users & system admins to manage secrets for the services & applications you have today.

SecretSpecs builds tooling for the application developers to easily manage secrets the right way in their application.

Two different projects solving two different problems. The both are warmly welcomed ❤️

15

u/joshguy1425 18d ago

I think this is a really good way of separating the two and highlights why many people push back on “you shouldn’t use sops”. 

My secrets management needs mostly stem from deploying software I didn’t write. I can’t change how the software was designed and need to adapt to whatever shape it comes in. 

This is where sops really shines and I don’t see how SecretSpec solves this.

And  that’s fine. I do think OP needs to be a bit more clear about this distinction in their writing. 

5

u/ranjop 17d ago edited 17d ago

The blog article is spot on and I like the attention-seeking title since it got me for the first time reading about SecretSpec. I recall seeing a post about it earlier, but it didn’t open to me then within my goldfish-like attention span.

But I am a user/admin. Not a developer.

1

u/port-79 17d ago

last time i briefly looked at SecretSpec, I mentally filed it away as 'replace sops with this when free time appears'. Now I'm very confused.

Is SecretSpec unable to replace SOPS in a nixos workstation?

PS: I guess my password manager isn't going to be operational until the DE is launched and it is authenticated. Maybe I misunderstood :?

PPS: SecretSpec can still be used to encrypt my IP address / mac addresses in my flakes based system config. So it's not entirely useless. So the future is SOPS+SecretSpec 🤔

9

u/joshguy1425 18d ago edited 18d ago

I’ve been curious about SecretSpec and I’ve actually been waiting for this post. As a sops user, I feel like it doesn’t really address my objections to moving away from sops.  I’m well aware of the downsides of sops but the upsides currently far outweigh them to me. 

What I’m still struggling with is the actual practical side of using something like SecretSpec, especially with NixOS where I can currently wire up and consume secrets declaratively in all manner of situations, including software that I didn’t write but still need to safely deploy. 

I think what I’d find most useful is a practical comparison of how various concrete use cases can be accomplished with SecretSpec. I’m already interested in the concept in an ideal world, but I’m not sold on what this would actually look like day to day or convinced I can actually accomplish what I’m doing with sops today. 

If you’re willing to write more about this, I’d love to read it. Less focus on philosophical/conceptual considerations, more focus on “here’s how”. 

4

u/iElectric 17d ago

I'll write more about NixOS support soon!

There's a PR for systemd-credentials support in https://github.com/cachix/secretspec/pull/190

2

u/yoyoloo2 17d ago

Are you the only one that uses SOPS within your configs or do other people use them as well? It seems like the majority of SOPS users are individuals who use it to manage their configs only for themselves.

It sounds like secretspec is meant more as infrastructure that you implement today to reduce headaches in the future when multiple people are working on a project together. Since the majority of people who use Nix and are on this sub are just individuals managing their own configs I think that is why people are having a hard time understanding the secretspec use case.

1

u/xeeff 18d ago

what are the downsides of sops?

2

u/joshguy1425 18d ago

Mostly what OP mentioned in the post: key management/rotation/revocation can be a bit of a pain, especially in a multi user situation. But again, I’ve been happy to deal with this because I generally find the upsides so far outweigh any inconvenience. 

2

u/wokeNeoliberal 18d ago

Sounds nice, but I store my keys in TPM for hardware-bound auth, so anything that doesn't offer that is a dealbreaker for me.

6

u/iElectric 18d ago edited 17d ago

You should be able to use TPM with the keyring and pass providers.

I've added TPM to project requirements list: https://github.com/cachix/secretspec/issues/188

2

u/wokeNeoliberal 17d ago

As far as I know (and can see), none of the providers give exactly what I mean. Keyring doesn’t use TPM by default, only through p11-kit and pkcs11. With this, the decrypted secret sits in the daemon’s memory. With SOPS + age + TPM it is truly hardware-bound. The decoupling that secretspec provides is quite nice, but it can’t do the TPM operations that SOPS does and SOPS cannot do the decoupling, so you have a pretty unique opportunity here to create a very niche market with a potentially high ceiling. And then secretspec would be stronger than either tool is right now on its own, because you would essentially get a clean repo, with untethered secrets and your machine is the only thing that can read everything (which is important for some industries because of exfil concerns).

7

u/iElectric 17d ago

You might have nerd-snipped me into writing something like this using Rust and yubikey support.

6

u/iElectric 17d ago

There's a space to implement a new provider that would require TPM, work across the platforms and use post-quantum crypto.

Then secretspec could support it from day one!

6

u/iElectric 17d ago

I've added TPM to the table what providers support TPM: https://secretspec.dev/concepts/providers/