Secret Lifecycle Management Story

[sini]

I’d like to start a discussion about encrypted secret lifecycle management with nixidy, and explore whether there’s a path toward a more native or upstreamable solution.

After reviewing public nixidy repositories, the dominant pattern appears to be external-secrets with backends like Vault or Bitwarden. While effective, that approach moves the source of truth outside of Nix.

My goal is to keep encrypted secrets (e.g., via sops/agenix) as the canonical source of truth within the Nix workflow.

Kubenix documents an approach using helm/vals as a preprocessing step for secrets. However, as far as I can tell, this pattern is not currently viable with argocd as-is. My recent work is largely about making a similar model viable in a nixidy-based workflow while preserving encrypted output.

My Current Approach

I’m currently using isindir/sops-secrets-operator and wrote a preprocessing utility that:

1. Builds all nixidyEnvs derivations for the current flake.

2. Diffs generated output against {nixidyEnv}.target.rootPath.

3. Transforms Secret resources into SopsSecret resources.

4. Pipes them through:

   • vals eval
   • sops -e
   • YAML re-serialization

Only encrypted manifests are written to disk.

This effectively makes a vals-style secret reference workflow usable with nixidy while preserving encrypted resources as the source of truth.

However:

• It bypasses the nixidy CLI and generated apply scripts.
• It relies on system key material (PGP/age), so it cannot run inside a pure derivation.
• Bootstrapping still requires out-of-band provisioning (e.g., agenix-rekey + systemd oneshot to create the initial decryption secret).

Functionally it works well, but architecturally it feels like I’m layering a transformation phase around nixidy rather than integrating with it.

Related Work

I found a somewhat similar pattern in duck1123/k3s-fleetops, which exposes decrypted inputs via environment variables during build, though it appears secrets may still enter derivation inputs.

I’ve also seen SOPS-encrypted YAML defined directly in nix configs, but that approach feels much harder to maintain and rotate long-term.

What I’m Looking For

I’d appreciate guidance on:

• Is encrypted secret transformation intentionally out of scope for nixidy?
• Would a formal “post-render transformation” phase or extension hook align with nixidy’s design?
• Is there a viable path to upstreaming something like this (potentially backend-agnostic: SopsSecret, SealedSecrets, etc.)?

I’m willing to invest time in turning my utility into a more general and polished solution if there’s architectural alignment.

Additionally, I don’t yet have a clean pattern for handling obfuscated-but-not-secret values (e.g., rendered hostnames). If there’s guidance there, I’d be interested.

[arnarg]

I wanted to keep this out of scope because there are so many secrets management solutions available that users can pick and choose from.

I'd be open to offering some hooks in the activation script if that would help with this (this is run by nixidy switch). Nothing explicit like secretHook but more like pre/post hooks in nixos' initrd generation: https://search.nixos.org/options?channel=25.11&query=boot.initrd.post

Would that be useful for you?

Edit: I guess this would have to run after the generated environment has been rsync'd to the rootPath, so maybe postSwitchCommands makes sense?

[sini]

If it's after the rsync then there's not /that/ much difference between that and just writing a shell wrapper. How could it integrate work with nixidy's bootstrapping 'apply' method? Expressing it purely in the nix context is likely problematic because it would require the secrets, either raw or their decryption keys, to enter the derivation and would hit the nix store.

[arnarg]

That's fair I guess. With some form of asymmetric encryption, the public key could be loaded and some kind of transformer would encrypt all secrets. Do note though that the entire helm template output is a derivation before it's imported again so if a secret comes from a helm chart it's not possible to encrypt it before it gets in the nix store.

Are you envisioning something specific? I'm always open to ideas.

[sini]

Let me chew on that for a couple days. I've been reading a lot of/all of nixidy's source and have getting deep into the weeds.

Looking at a project like agenix-rekey which is built on top of agenix, it has to go through the decrypt/re-encryption problem as well. That project's implementation happens entirely in a userspace utility -- though it supports processing nix derivation functions to define its generator functions which yield scripts to execute. I assume that's simply to create the barrier between the nix store.

Perhaps some sort of 'object' transform mapper method chain interface could be exposed and called by the nixidy CLI utility, though I'm uncertain at the moment what that interface would look like exactly and would likely result in more build logic moving outside of flake.

[sini]

Just wanted to update that I'm still thinking on this -- I just opened a PR against agenix-rekey to add support for non-nixosConfiguration/homeManagerConfiguration objects and the plan is to prototype something that can be more natively integrated with/fed to nixidy. I built an example extension agenix-rekey-to-sops to rekey from raw agenix to sops yaml.

I'll update again in a week or so when I have a working end-to-end prototype.