nixos/step-ca: Declarative step-ca service

[mohe2015]

Previous conversation participants: @tashian @midchildan @aanderse

Motivation for this change

Create a declarative step-ca module instead of a more or less imperative one (which is likely hard to use and maintain using nix).

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[r-rmcgibbo]

Result of nixpkgs-review pr 112322 at 91acf595 run on x86_64-linux 1

1 package blacklisted:

• tests.nixos-functions.nixos-test

1 package built:

• step-ca

[r-rmcgibbo]

Result of nixpkgs-review pr 112322 at 91acf595 run on aarch64-linux 1

1 package built:

• step-ca

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/typechecking-options-based-on-a-key/11517/1

[midchildan]

Thanks for your work! I think this PR is in better shape than the previous one as it would support a wider range of use cases.

I believe we can do with fewer suboptions though, considering that the easiest way to configure this module would be to generate it using step ca init and import it using builtins.fromJSON. So instead of trying to describe every option in ca.json, it'd be more helpful if we document how to configure this module in settings.description. Reducing the number of suboptions would also improve maintainability, because keeping the options accurate and in sync with upstream would require constant effort.

How can I type the provisioners option where the type option defines the available other options.

You could create custom types, but I think listOf anything is enough.

[Church-]

Yeah this does appear better and easier to use then the previous module we worked on @mohe2015

Thumbsup from me.

[midchildan]

This module might also benefit from having an openFirewall option.
https://search.nixos.org/options?channel=20.09&from=0&size=50&sort=relevance&query=openfirewall

[mohe2015]

@midchildan Thanks a lot for the review and easy-to-apply Github suggestions. I implemented an openFirewall option but I don't know if there would be a better way to do this as unfortunately upstream doesn't have a port option.

[mohe2015]

@ofborg build step-ca

I fixed a fixed-output hash. Should be good to merge when ofborg also builds.

@r-rmcgibbo is it possible to trigger a rebuild?

[tashian]

Hi @mohe2015, just a thought I had today about what else would make certificate management easier in NixOS. If this belongs on some other forum let me know, I'd love to join in the discussion.

I came across this blog post from @Xe about setting up Grafana, Prometheus, loki, and node_exporter using NixOS. They mentioned doing TLS configuration using a custom CA. In their config it looks like they're pulling PEM files from an external HTTPS endpoint during setup.

It got me wondering what it would take to make ACME and shorter-lived certs possible on the service level in NixOS, with automated renewal. Does NixOS have an ACME client that could be composed with services like NGINX that don't have internal ACME support? I think it would be an excellent complement to the step-ca package.

For step-ca we have a TLS cert renewal approach that uses systemd timers, but the cert-renewer@ service almost always needs to be overridden to make renewal work for a given service. Certificate files have to be installed into a service-specific location, or the service has to be sent a HUP signal or restarted, etc. And if you want to add configuration for mutual TLS authentication (we ❤️ mTLS), things get a little more complex because now clients need certs too.

It would be amazing if there were some sort of NixOS cert management "sidecar" that just knew how do the right thing for a given service, and could be configured with an ACME CA.

[mohe2015]

@tashian I'm short on time right now but there actually already are options for enabling ACME. https://nixos.org/manual/nixos/stable/options.html#opt-services.nginx.virtualHosts._name_.enableACME is the option for nginx (Page loads really slow) and there exists the same option for apache2. As most services use these as reverse proxies almost every service has this builtin and otherwise you can and usually need to put them as a reverse proxy in front.

https://nixos.org/manual/nixos/stable/#module-security-acme-nginx is a bigger example from the official manual and I use step-ca in my test setup the following way:

{
  security.acme.server = "https://localhost:9443/acme/acme/directory";
  security.acme.email = "[email protected]";
  security.acme.acceptTerms = true;

  services.step-ca = {
    enable = true;
    address = "127.0.0.1";
    port = 9443;
    intermediatePasswordFile = "/etc/nixos/secrets/pi-smallstep-ca"; # FIXME is world readable
    settings = {
      dnsNames = ["localhost"];
      root = ../../../secrets/root_ca.crt;
      crt = ../../../secrets/intermediate_ca.crt;
      key = ../../../secrets/intermediate_ca.key;
      db = {
        type = "badger";
        dataSource = "/var/lib/step-ca/db";
      };
      authority = {
        provisioners = [
          {
            type = "ACME";
            name = "acme";
          }
        ];
      };
    };
  };
}

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/security/acme.nix contains the source of the acme module. The default seems to be checking daily for renewal which can also be configured. I don't know how good support for mTLS is but this would probably need to be implemented into nginx if it isn't already. If there is a simple config flag then you could also easily enable this in your local configuration.

I don't know how well the services work with updating the certificate but that could probably be found out easily.
Edit: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-servers/nginx/default.nix#L820 seems like nginx automatically reloads on renewal although I didn't read the code that thoroughly.

[mohe2015]

I added myself as a maintainer and bumped the version to 0.15.10 instead of 0.15.8. There don't seem to be any relevant changes mostly small documentation things.

I would love to get this merged before 21.05 and maybe adding myself as a maintainer explicitly helps.

[SuperSandro2000]

@aanderse could you please take a look at the module?

[aanderse]

Great work on the module. Great support from upstream. Team effort. What more could you ask for? 🎆

There are a ton of comments so I apologize if this has already been discussed... but I just wanted to confirm that everyone understands exactly what these lines implies:

        restartTriggers = [ configFile ];
        reloadIfChanged = true; # allow reloads for more service availability

To clarify: the service will never automatically restart, even when software is upgraded. The sysadmin must manually restart the service any time the binary is updated if they want the new binary. Based on what the software does I figure I would just double check given the security implications on OS patching.

[mohe2015]

Great work on the module. Great support from upstream. Team effort. What more could you ask for? 🎆

There are a ton of comments so I apologize if this has already been discussed... but I just wanted to confirm that everyone understands exactly what these lines implies:

        restartTriggers = [ configFile ];
        reloadIfChanged = true; # allow reloads for more service availability

To clarify: the service will never automatically restart, even when software is upgraded. The sysadmin must manually restart the service any time the binary is updated if they want the new binary. Based on what the software does I figure I would just double check given the security implications on OS patching.

@aanderse Oh no, that's bad. Is it possible to get both behaviours so reload on configuration change and restart on binary change? I'm on my phone right now but as far as I remember the documentation of these options is pretty bad currently.

[aanderse]

Unfortunately it is not...

ping @flokli we should probably do something about this finally.

[mohe2015]

@aanderse I removed reloadIfChanged = true;. Is this fine now to get merged?

[aanderse]

I approve the module portion of this PR 👍