Store Certificates in Kubernetes Secrets

[mmack]

Hey, thanks for that project!

It would be awesome if we can use a Kubernetes secret to store the state file. See: https://kubernetes.io/docs/concepts/configuration/secret/

As i see it it's only updated every 8 hours, right? That would be no problem with k8s secrets.. What if i boot 10 instances of the same container? Are they all updating the state file?

[jedisct1]

Hi!

The state file is essentially a backup of the in-memory state. Keys are rotated in memory, then dumped to disk; the file is never loaded except at startup time.

So, if multiple instances share the same file, this is still not going to make them use the same ephemeral keys. Which is actually totally fine, if and only if a given client is always going to hit the same container.

Using a K8S secret the same way would have the same limitation.

But that can be fixed, and I have a plan for it, that is not going to require synchronization. Generate the ephemeral key pairs using a forward-only rolling state instead of them being completely non-deterministic. That way, assuming that the rotation interval is constant (8 hours, as you correctly found), any node can compute the current key pair from any previous state.
And this will still provide forward security, up to the previously known state.

This may require a bit of changes, but I'll look into it. Even beyond K8S, that can be very useful for people running multiple servers for load-balancing or failover.

[mmack]

So currently it's not possible to have multiple containers with the same sdns stamp, ist that correct?

[jedisct1]

It is!

The stamp only includes long-term keys.

These long-term keys are used to sign short-term keys, that are rotated every 8 hours.

Multiple servers can have the same stamp. But since short-term keys are maintained by individual instances, if a client retrieves a certificate from a container, and then sends queries to a different container, shared keys won't match.

[jedisct1]

This still require testing, but these changes have been made.

Now, you can start the server once just to create an initial state, then copy that state on as many nodes as you want, and they will all be computing the same ephemeral keys, without explicit synchronization.

The state file can be shared, or each node can have its own.

Still, the state file should not be read-only. Always starting from the original state would work, but the startup time is proportional to how old the previously saved state is.