Inoculate host identity on first use

[blaggacao]

You wrote in a commit message that some ssh prep is necesarry to put a specific host under deploy-rs control.

I've spent some time in the past to conceptually solve this issue and to inoculate an anonymous os image copied over to a host with identiy over a link local connection.

The idea is:

• Take a network cable
• take an anonymous host without identity and a pre-existing, minimal and generic inoculation image that listens on a well-known link-local ip address
• Plug the cable on one end into host and on the other end into my workstation
• run deploy-rs command to inoculate with a generic inoculation deployment (which estabilshes identity and everything bound to it such as IP address and host name)
• disconnect and put the host in the final place
• run deploy-rs on the new identity

For inoculation, I'm using a spiffe workload identity attestation procedure based on a TOFU join token and a pre-existing declarative host definition, that's all.

Currently, this procedure is not quite nixified, yet. Should it be possible to pass arguments to deploy-rs, I don't see any reason why this workflow could not be made first-class.

I plan to rebase my little env on divnix/devos in the coming days and we'll see where that leads me to.

[blaggacao]

A good read on the (broader) topic: https://smallstep.com/blog/everything-pki/

[blaggacao]

Hi @tashian, @mohe2015 relayed me to you: Do you think this host identity inoculation is a use case that can be implemented with step-ca instead of spiffe based on a host join token of some sort? (Or does step-ca even use spiffe under the hood for workload / host authentication?)

[nrdxp]

Will be helpful when merged:
NixOS/nixpkgs#112322

[tashian]

Hi @blaggacao! We don't use spiffe, but step-ca can provision a one-time-use JWT (using step ca token) that can be exchanged for a host certificate from the CA. From the docs:

step-ca produces JWTs that:

• are short-lived (5 minute lifespan)
• are one-time-use tokens (during the lifetime of the step-ca)
• have a 1 minute clock drift leeway

Does this help?

cc @mmalone

[mmalone]

Heyo. Like @tashian said, we don't currently "do spiffe" but we can probably do what you need. There are a few different pieces of spiffe...

If all you need is a host cert issued at deploy time and renewed automatically then you probably don't need spiffe at all. You can use the JWT mechanism @tashian mentioned above which is basically a "TOFU join token" mechanism, as you've described.

If you want to name your host using an SVID/spiffe ID (e.g., spiffe://trust-domain-name/path) instead of a DNS name you should be able to use the JWT mechanism plus a custom certificate template to drop the SVID into the right place in the cert.

We don't currently implement the spiffe workload attestation API or the federation APIs. I could see us some day implementing the federation APIs to become a "spiffe issuing authority", but I don't think it makes sense for us to re-implement the workload attestation APIs (that's what spire does).

I am interested in documenting spiffe use cases, so if anyone has thoughts please do share!

[blaggacao]

[...] you should be able to use the JWT mechanism plus a custom certificate template to drop the SVID into the right place in the cert.

That is awesome!

[tashian]

@blaggacao Just wanted to add here a link to our full docs on cert templates

[blaggacao]

• Take a network cable
• take an anonymous host without identity and a pre-existing, minimal and generic inoculation image that listens on a well-known link-local ip address
• Plug the cable on one end into host and on the other end into my workstation
• run deploy-rs command to inoculate with a generic inoculation deployment (which estabilshes identity and everything bound to it such as IP address and host name)
• disconnect and put the host in the final place
• run deploy-rs on the new identity

Looks like @Xe has solved the bootstrapping thinking in a similar way with "link local" (fixed, well-known) IP addresses: https://github.com/Xe/nixos-configs/blob/ec73a55b42836ef194a38c8bad5a938e11f3b979/hosts/lufta/bootstrap.nix

/cc @Xe It would be nice if you could complement your thoughts / experiences

[Xe]

That bootstrap file is used to build a kexec tarball so I can install NixOS on the server (or reinstall it on the server should my luck change).