Proposal: SPIFFE and SPIRE Integration for nono

[lukehinds]

SPIFFE and SPIRE can integrate with nono and fill a key gap in nono's capability - giving workload identity to the unsandboxed nono supervisor/proxy, preventing the handing of SPIFFE credentials directly to the sandboxed agent.

So nono already has a strong split:

• the sandboxed child is restricted with fine-grained kernel isolation primitives.
• outbound network access can be forced through nono-proxy
• the proxy owns credential injection, endpoint filtering, TLS handling, OAuth2 exchange, and can write to supervisor owned audit events

One approach is to extend nono-proxy so routes can authenticate to upstream services with SPIFFE X.509-SVIDs or JWT-SVIDs obtained from a local SPIRE Workload API (outside the sandboxed child). This way the sandboxed agent continues to see only a localhost HTTP interface but with phantom credentials. Real workload identity material remains outside the sandbox, leveraging the supervisors existing backends.

Existing nono Fit (why SPIFFE / SPIRE and nono = best friends).

The current architecture already has the pieces needed for a clean integration ("so much room for activities"):

• nono core exposes CapabilitySet and NetworkMode, including ProxyOnly.
• nono-cli decides when the proxy is active and grants only the capabilities needed by the child.
• nono-proxy owns reverse proxy routes, endpoint filtering, credential loading, OAuth2 token exchange, TLS connectors, and audit events.
• Route config already has upstream mTLS file fields: tls_client_cert and tls_client_key.
• Audit/session code already persists session metadata and can be extended to include identity context.

This strongly suggests SPIFFE should be a CLI/proxy feature, but having primitives in the core nono crate is interesting for the nono libs (py,ts,go) - so we should see what's possible there.

So what's the value?

A good many Organizations / kube shops that already use SPIFFE/SPIRE we also want capability control of AI agents ability to call internal services without long-lived API keys. Today, nono can keep static credentials out of the sandbox by proxying and injecting them, but there is no first-class way to:

1. use SPIRE-issued X.509-SVIDs for upstream mTLS;
2. use JWT-SVIDs as bearer credentials or token-exchange assertions;
3. record the SPIFFE identity associated with a nono session;
4. constrain internal API access by both nono policy and workload identity;
5. keep the SPIRE Workload API socket and SVID private keys away from the untrusted agent.

Of course the dangerous shortcut is to grant the sandboxed child read/write access to the SPIRE agent socket. That may be acceptable in some deployments, but it changes nono's threat model, so it's a definite "nono": the agent can obtain identity material and use it without the proxy's endpoint filtering, audit mediation, or phantom-token boundary , giving us a supervisor boundary - to use the due an update image, it sits alongside the audit and cred store

Goals

1. Allow nono-managed workloads to authenticate to internal SPIFFE-aware services.
2. Keep SVID private keys and real identity-bearing tokens outside the sandbox by default.
3. Preserve nono's proxy-mediated credential isolation model.
4. Support both X.509-SVID mTLS and JWT-SVID flows.
5. Make SPIFFE identity visible in audit/session records.
6. Keep the core library policy-free and SPIFFE-free.
7. Fail closed on SPIRE unavailability, missing identity, bad trust bundles, or upstream identity mismatch

Non-Goals

1. Turning nono into a SPIFFE Workload API implementation.
2. Replacing SPIRE agent workload attestation.
3. Granting ambient access to /run/spire/sockets/agent.sock by default. "i will never do such a thing"
4. Embedding SPIRE server registration management in nono.
5. Making SPIFFE identity a substitute for nono filesystem, process, network, or endpoint policy.
6. Supporting sandbox expansion after identity issuance. Once the OS sandbox is applied, the no-escape-hatch rule remains.

Possible

PLease review SPIFFE experts.

Add SPIFFE-aware route authentication to nono-proxy, configured through profiles and manifests.

The sandboxed agent still calls:

http://127.0.0.1:<proxy-port>/<service>/...

The proxy:

1. obtains an SVID from the local SPIRE Workload API;
2. enforces route and endpoint rules;
3. authenticates to the upstream using SPIFFE identity;
4. verifies the upstream SPIFFE ID when configured;
5. records the identity context in network audit events.

Design

1. X.509-SVID Route Authentication

Add a route auth mode for upstream mTLS:

{
  "network": {
    "custom_credentials": {
      "internal-api": {
        "upstream": "https://api.internal.example",
        "auth": {
          "type": "spiffe_x509",
          "workload_api_socket": "/run/spire/sockets/agent.sock",
          "svid_hint": "internal",
          "expected_upstream_spiffe_id": "spiffe://prod.example/internal/api"
        },
        "endpoint_rules": [
          { "method": "GET", "path": "/v1/tasks/**" },
          { "method": "POST", "path": "/v1/tasks/*/comments" }
        ]
      }
    },
    "credentials": ["internal-api"]
  }
}

Behavior:

• nono-proxy connects to the SPIRE Workload API over UDS.
• It requests X.509-SVIDs and trust bundles.
• If multiple SVIDs are returned, svid_hint selects the intended identity; otherwise the SPIFFE default identity behavior applies.
• The proxy builds a per-route rustls client config using the SVID certificate chain, private key, and trust bundle.
• The proxy validates the upstream certificate URI SAN against expected_upstream_spiffe_id when present.
• SVID/key rotation updates the in-memory connector without restarting the sandboxed child.

Must-haves:

• The SVID private key must never be written into a child-readable file.
• Debug formatting and logs must redact SVID key material.
• If the Workload API stream redacts the selected SVID, the route becomes unavailable.
• If the upstream identity does not match policy, the connection is denied and audited.

2. JWT-SVID Route Authentication

Add a route auth mode for bearer-style identity:

{
  "network": {
    "custom_credentials": {
      "inventory": {
        "upstream": "https://inventory.internal.example",
        "auth": {
          "type": "spiffe_jwt",
          "workload_api_socket": "/run/spire/sockets/agent.sock",
          "audience": ["inventory.internal.example"],
          "inject_header": "Authorization",
          "credential_format": "Bearer {}"
        },
        "endpoint_rules": [
          { "method": "GET", "path": "/v1/items/**" }
        ]
      }
    },
    "credentials": ["inventory"]
  }
}

Behavior:

• The proxy requests a JWT-SVID with the configured audience.
• The proxy injects it into the upstream request according to the route config.
• The sandboxed child receives only the normal phantom token.
• JWTs are refreshed before expiry.

This is useful for services that do not accept client certificate mTLS but can validate SPIFFE JWTs, or for token-exchange flows where a JWT-SVID is used as a client assertion.

3. JWT-SVID as OAuth2 Client Assertion

Extend the existing OAuth2 route support with a SPIFFE assertion source:

{
  "oauth2": {
    "token_url": "https://auth.internal.example/oauth/token",
    "client_assertion": {
      "type": "spiffe_jwt",
      "audience": ["https://auth.internal.example/oauth/token"]
    },
    "scope": "tasks:read tasks:comment"
  }
}

The proxy exchanges the JWT-SVID for an access token, caches the token, and injects the resulting access token upstream. This keeps compatibility with APIs that standardize on OAuth2 while still eliminating long-lived client secrets.

4. Session and Audit Identity Context

Add optional SPIFFE fields to session and audit records:

{
  "spiffe": {
    "workload_id": "spiffe://prod.example/nono/proxy",
    "trust_domain": "prod.example",
    "svid_type": "x509",
    "source": "spire-workload-api"
  }
}

Network audit events should include route-level identity context:

{
  "route": "internal-api",
  "auth": {
    "mechanism": "spiffe_x509",
    "source_spiffe_id": "spiffe://prod.example/nono/proxy",
    "upstream_spiffe_id": "spiffe://prod.example/internal/api"
  }
}

We use the scrubber to ensure audit record should not contain private keys, JWT bodies, raw certificates unless explicitly scrubbed, or full SVID material.

SPIRE Attestation Considerations

SPIRE issues workload identity by matching attested selectors against registration entries. Plain Unix selectors such as UID, GID, and executable path may not distinguish:

nono run --profile prod-readonly -- agent
nono run --profile broad-dev -- agent

Both may have the same binary path and Unix user.

Possible deployment models:

1. Proxy identity model
   SPIRE identifies the nono supervisor/proxy as the workload. nono then enforces per-profile and per-route policy internally. This is the initial recommended model.

2. Kubernetes identity model
   SPIRE uses Kubernetes selectors such as namespace, service account, pod labels, and container name. nono handles finer-grained policy inside the pod.

3. nono-aware SPIRE attestor
   A future SPIRE workload attestor could inspect nono session metadata and expose selectors such as profile name, manifest digest, package identity, or audit session ID. This should be considered only after the proxy identity model proves insufficient.

impact of AF-UNIX Pathname Mediation (update from 2026-05-22)

AF-UNIX pathname mediation has landed. This changes the
threat model meaningfully and closes several questions that were left open in
the original proposal.

The supervisor now installs a seccomp-notify filter (Linux) that intercepts
every connect(2) and bind(2) syscall from the sandboxed child. The filter
routes calls through the supervisor's decision function, which:

• Allows only pathname sockets whose path matches an entry in the
  UnixSocketCapability allowlist that the CLI builds from profile fields.
• Denies everything else: abstract-namespace sockets (sun_path[0] == '\0'),
  unnamed sockets, and any pathname socket not in the allowlist.

The profile surface is:

{
  "linux": { "af_unix_mediation": "pathname" },
  "unix_socket": ["/run/spire/sockets/agent.sock"]
}

Without unix_socket granting the SPIRE socket, the child receives EACCES
on any connect attempt, and the denial is captured in the session audit as an
IpcDenialRecord with path, operation, and suggested remediation flags.

What this changes for the SPIFFE integration

Explicit Socket Access Policy is now backed by active OS-level
enforcement, not just capability absence. The original proposal described a
passive model where the SPIRE socket was simply not granted; the mediated model
intercepts and logs actual attempts. The threat of an agent discovering and
trying to open /run/spire/sockets/agent.sock by inspecting /proc or
environment variables is now stopped at the syscall boundary with an audit
record, not silently ignored.

The opt-in mechanism the proposal described — an explicit CLI flag or profile
field — maps directly onto unix_socket grants. There is no separate
expose_workload_api_to_child toggle needed; the existing UnixSocketCapability
grant model covers it cleanly.

macOS gap

AF-UNIX pathname mediation is Linux-only. On macOS, Seatbelt controls socket
access via the (deny network-outbound (path-literal ...)) predicate or
(deny ipc-posix*) rules. The proxy-owned SPIRE socket model still applies
on macOS, but the active intercept-and-audit layer is absent.

[damixcoder]

shut up and take my money. big vote for having this, it would close real existing gaps

[lukehinds]

Knowing its useful and of value is all the money i need @damixcoder !

[elinesterov]

Yes, I'd love that support for agents. Can add the ability to authenticate to MCP servers using SVIDs, fetch creds from centralized store, and do all sorts of auth, including WIF if needed.

off-topic: How did you generate the diagram? I love it!

[lukehinds]

Sounds good, I am little weak in this area so can't give much feedback but would love to learn more. So SVID would be given to an MCP server running in nono and allow it to provide auth etc?

The diagram, I sketched it out in a messy way in google slides and then asked AI to make a clean version

[sublimino]

This look great, we can see value that could be on both sides. Use the SVID inside the sandbox for authn/z and outside for signing. That signing could be done by Witness too, as we've got build capture/attestor workflows for this we'd extend. /cc @jkjell @06kellyjac