Security
Who issues the certificates, and where the keys are held
The short answer: Infraspawn runs a certificate authority for each network you create, signs a certificate for every machine on it, and holds that material encrypted in our database until the machine asks for it. This page is the long answer, including the part we chose to trade away.
When you create a network
Each network gets its own certificate authority
Creating a network generates a certificate authority for that network and nothing else. It is encrypted before it is stored, and it exists to sign the certificates of the machines you put on that network.
Because the authority belongs to one network, a certificate issued on one network proves nothing on another. That is what makes the isolation between two networks structural rather than a rule somebody maintains: a machine on your customer A network is not trusted on your customer B network, and there is no policy in between the two that could be edited to make it so.
The certificate authority is generated when the network is created, and it is not exported. There is no step where it travels to a machine, and no copy of it on any machine at a site.
When you create a machine
A certificate and a key per machine, signed by that network
Creating a machine generates a key pair for it and a certificate carrying its address on the mesh, signed by that network's authority. Both are encrypted and stored against that machine, and you are handed one thing: the node key.
The node key is a long random secret that identifies one machine. You install the agent with it, and it is the only thing that goes to the site. Nothing else has to be copied there, and nothing has to be typed into a config file by whoever is standing in the building.
The machine then makes one request to us over TLS, presenting its node key, and receives its certificate, its private key, and the configuration for what it should be running. That is the whole bootstrap. There is no inbound connection, no port to forward, and no listening service exposed at the site for us or anyone else to reach. Everything is initiated from the machine.
The tradeoff
We generate the key, and we could read it
This is the part worth being direct about, because it is the design decision underneath everything above.
A machine’s private key is generated on our side and held encrypted in our database, rather than generated on the machine and never leaving it. The stricter design is well understood: the machine makes its own key, sends us a signing request, and we sign a certificate without ever holding the private half. We went back and forth on this during the initial design and chose the simpler one on purpose.
What it buys is that a machine is set up with one secret and one command, on hardware nobody has to prepare in advance, by whoever happens to be on site. What it costs is that the trust is real: our infrastructure could decrypt a node’s key, so we are inside your trust boundary rather than beside it. Encrypting the material at rest protects it against a database being read; it does not claim to protect it against us.
We would rather say that than imply otherwise. The signing-request design is the natural next step, and it is a scheme we intend to support for customers who require their key material never to exist off the machine. If that is a requirement for you rather than a preference, tell us, because that is what decides when it gets built.
If something leaks
What each credential can actually do
Blast radius matters more than the number of credentials, so here is what each one is worth to somebody who takes it.
Node key
On the machine, written at install time
- What it allows
- Acting as that one machine: fetching its certificate, its configuration, and the recipes for the services assigned to it.
- If it is lost
- Someone who takes it can impersonate that machine on that one network. They cannot create machines, create networks, reach another network, or read anything belonging to another customer. Most services on top ask for their own credentials as well.
- How it ends
- Ends when the machine is removed from the network, and expires with the network if the network has a deadline.
Access key
Wherever you drive the CLI or the API from
- What it allows
- Creating and changing networks, machines and services in your account. This is the powerful one, and it is the one to treat like a deploy credential.
- If it is lost
- Someone who takes it can act as you against your own account, within the limits of your plan.
- How it ends
- Revoke it on the account page. Keys can also be given an expiry when they are created.
Dashboard login
With the person
- What it allows
- The same account, through the browser.
- If it is lost
- The same as an access key, plus the ability to issue new ones.
- How it ends
- Ordinary account controls.
Between machines
What protects the traffic itself
Once a machine has its certificate, the mesh is what carries everything else.
Traffic between two machines is encrypted between those two machines, and each side proves it holds the key for the identity it claims. Membership of a network is a second, separate gate: joining requires a shared secret derived from that network’s own certificate authority, which a machine only ever receives by authenticating with its node key. A machine that has not been issued onto your network cannot complete a connection to anything on it, which is the mechanism underneath the claim that two networks cannot reach each other.
Connections are direct wherever the two ends can reach each other, and relayed through a meeting point when they cannot. A relay forwards the connection without being able to read what is inside it, because the encryption is negotiated between the two ends, through it. Which meeting point is used is a choice you make, and running that meeting point on your own servers is on the roadmap for enterprise customers.
Services deployed on top of the mesh usually have their own authentication as well. The mesh decides who can reach a service at all; it is not a substitute for the service asking who is calling.
Where we are
What this page does not claim
Infraspawn is in private pilots, and the honest description of the security posture is that it is a considered design that has not yet been through an external audit.
There is no third-party penetration test, no formal certification, and no compliance programme behind this page yet. Nothing above should be read as any of those. What it is: an accurate description of how the system works today, written so that you can decide whether the model fits what you are responsible for.
If you have found something, or you need detail this page does not cover, write to us and you will get a straight answer from an engineer rather than a form.
Ask us the awkward version of the question
If your security review has requirements this design does not meet yet, we would rather hear them now than find out later. They are what decides the order things get built in.