Skip to content

Signed instance identity document over the /dev/incus guest API #3908

Description

@jmgilman

Is there an existing issue for this?

  • There is no existing issue for this feature

What are you currently unable to do

Verify that metadata read from /dev/incus/sock was produced by Incus. GET /1.0 and GET /1.0/meta-data return plain JSON with no signature, so a party outside the guest cannot trust claims forwarded from it.

I built a SPIRE NodeAttestor for Incus VMs (componere/incus-spire-attestor). A SPIRE Agent inside the guest reads its identity from /dev/incus/sock and presents it to the SPIRE Server. Because the claims are unsigned, the server must treat them as a locator only: it looks the instance up through the main Incus API with its own client certificate, then proves residency by writing a single-use nonce into the instance's user.* configuration and requiring the guest to read it back through /dev/incus/sock.

This works, but at two costs:

  1. The verifier needs an Incus client identity with can_edit on the attested instances. That entitlement is not scoped to user.* keys. Meaning, the same identity can modify, rename, or delete those instances.
  2. Each attestation is an instance lookup, an ETag-guarded config write, and a cleanup write on the Incus server.

What do you think would need to be added

A guest API endpoint that returns a signed identity document, for example:

GET /1.0/identity?nonce=<hex>

Incus already resolves the requesting instance from the socket credentials and scopes every /dev/incus/sock response to it. The new endpoint would put that server-side knowledge into a verifiable form:

  • Payload: instance name, project, type, volatile.uuid, location or cluster member, a server timestamp, and the caller-supplied nonce.
  • Signature: made by a server- or cluster-held private key, with the public key available to verifiers out of band, for example through the main API or the cluster trust store.

A verifier checks the signature and the nonce it chose. It needs no write access to Incus, and freshness comes from the nonce instead of a config write.

This is the pattern the major cloud metadata services use: AWS serves a PKCS7-signed instance identity document, GCE serves a signed identity JWT with a caller-chosen audience, and Azure signs a caller-supplied nonce through its attested data endpoint. SPIRE, Vault, and step-ca all consume these documents for node attestation. A signed document from Incus would let the same pattern work on Incus and IncusOS clusters without a TPM.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    MaybeUndecided whether in scope for the project

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions