On the possibility of a SPIFFE Spire plugin

What is SPIFFE Spire?

SPIFFE is a specification that describes a system for trusting workloads running on platforms.

Spire is the official reference implementation of SPIFFE.

There are many ways to deploy Spire, but generally you have these components.

  • A central spire-server; holds an intermediate CA that can issue certificates
  • Any number of spire-agent instances, running on all your nodes. They phone home to the spire-server
  • Your running code, aka a workload; The workload (or, perhaps, a service mesh sidecar to the workload), talks to the local spire-agent, usually over a unix domain socket. If the spire-agent decides your workload is not an attacker (a process they call workload attestation), it requests a new cert identity (the so-called SVID in Spire jargon), and gives it back to your workload

In practical terms, Spire is a structured way to do mTLS across a fleet of microservices, with minimal attack surface. The operator trusts a select few components (the cloud platform, maybe), sets up Spire, and gets mTLS and short-lived, frequently-rotated certificates.

On Kubernetes, a spire-agent runs as a DaemonSet, and it’s privileged. The spire-agent listens on a unix socket at a well-known path on the underlying host. Workloads mount that socket from the host, and talk to the agent that way.

Spire + LXD?

I am trying to think of a least-privilege way one would do this in an LXD server, or even an LXD cluster.

One strategy is to run the spire-agent directly on the LXD host, and bind mount a socket in.

Another strategy is to run agents inside each container Instance, and just treat them as whole unix systems, using the already-existing Unix attester plugin. But that seems like a waste of resources, at least compared to K8s.

Is there a way to run the agent in a container and share a bind mount only between containers? Is there a way to do this without privileged containers? Furthermore, can the LXD daemon be queried to determine the following information about what’s running on a server:

  • processes running in a container, UID, GID
  • where binaries are on the “real host”

The spire-agent itself usually needs high privileges, although this can be adjusted based on your security posture. But it usually needs access to PID namespace, user namespace; And if you want to checksum the binaries of running processes, you need access to the filesystem.

Anyway, if anyone has ideas, I’d appreciate it. I want to see what’s possible with LXD.


UPDATE: Sharing a folder between unprivileged containers is apparently possible with shiftfs, which I haven’t tried yet LXD usecases of shiftfs (volume-/disk-share)

One piece of the puzzle:

A plugin, no matter where it’s run, could be given access to the REST API.

exec could be run by the plugin

https://linuxcontainers.org/lxd/api/master/#/instances/instance_exec_post

This effectively would let the plugin inspect just about anything in the containers it would be attesting.

Useless comment but you seem to have a need - why dont you write the plugin / startergy? Didn’t you write the Ansible one?

What advantages does the LXD team get from working with this? First time i’d heard of this service is when you posted it.

Years ago I feel like someone proposed something similar but go nowhere.

Not a useless comment :slight_smile:

And I imagine that many are not familiar with SPIFFE or SPIRE. This video is an excellent overview of the architecture

I do plan on writing the Spire LXD attestation plugin at some point. I actually think LXD is a great thing to integrate with SPIRE, because LXD has native support for TPM devices.

The plugin I authored before was for Puppet Bolt, which is similar to Ansible. Technically, I started writing the plugin, but Lucy and Tom and Puppet were kind enough to help me get my PR over the line.

Much like in the Bolt plugin case, it all started with a forum post and a crazy idea :slight_smile:

I always wish projects like this and the one you started with Puppet Bolt success, they are great additions to the LXD ecosphere and its valuable work.

I think the video introduction is a great addition to this thread but If I were you and wanted peoples attention id sell the user numbers & benefits from an intergeneration over the tech.

LXD team has chosen to integrate with a very specific number of technologies over the years (even to the extent they ignored LDAP for Canonicals home-grown solution) and you may find it hard to get the attention you want.

As always, best of luck :heart: