Implement SPIFFE Broker Endpoint & API by arndt-s · Pull Request #6594 · spiffe/spire

arndt-s · 2026-01-21T12:06:11Z

This is a Work In Progress.

Reference implementation for spiffe/spiffe#340

api-sdk PR: spiffe/spire-api-sdk#92
plugin-sdk PR: spiffe/spire-plugin-sdk#71

Pull Request check list

Commit conforms to CONTRIBUTING.md?
Proper tests/regressions included?
Documentation updated?

Affected functionality

Description of change

Which issue this PR fixes

Signed-off-by: arndt-s <17650715+arndt-s@users.noreply.github.com>

arndt-s

Self review highlighting parts that I would like to get feedback/opinions on please.

proto/brokerapi/brokerapi.proto

arndt-s · 2026-01-21T12:23:11Z

conf/agent/agent_full.conf

    # admin_socket_path = ""

    # authorized_delegates: SPIFFE ID list of the authorized delegates
    # authorized_delegates = [


I'm unsure whether we should allow for a dedicated allow list for the broker endpoint or reuse the same?

arndt-s · 2026-01-21T12:23:49Z

cmd/spire-agent/cli/run/run_posix.go

 	return c.AdminSocketPath != ""
 }

+func (c *agentConfig) getBrokerAddr() (net.Addr, error) {


For now I'm only supporting UDS, once the Broker API evolves we may allow serving it on TCP too.

arndt-s · 2026-01-21T12:24:07Z

pkg/agent/attestor/node/result.go

+)
+
+// Allow AttestationResult to be used as go-spiffe SVID and bundle sources.
+// TODO(arndt): Check whether the key of the agent is ok to be exposed to other parties.


I think this is worth a discussion.

arndt-s · 2026-01-21T12:24:42Z

pkg/agent/agent.go

+			TrustDomain:         a.c.TrustDomain,
+			AuthorizedDelegates: a.c.AuthorizedDelegates,
+			SVIDSource:          as,
+			BundleSource:        manager.GetX509Bundle(),


I wasn't sure what's better here, us the attestation result as a bundle source or the one from the manager?

arndt-s · 2026-01-21T12:25:49Z

pkg/agent/broker/api/service.go

+	if err != nil {
+		return err
+	}
+	_ = rpccontext.Logger(ctx).WithField("broker_peer", peer.String())


There's no log here .. I'm considering to add Debug logs for each RPC?

arndt-s · 2026-01-21T12:26:18Z

pkg/agent/broker/endpoints.go

+}
+
+func New(c *Config) (*Endpoints, error) {
+	switch {


Is this pattern ok? Delegated Identity doesn't have it and would panic if misconfigured?

arndt-s · 2026-01-21T12:26:35Z

pkg/agent/broker/endpoints.go

+
+	// TODO(arndt): Delegated Identity API allows to be served without any authorized peer.
+	// I think it's better to fail as it's a misconfiguration and having that socket up
+	// without any authorized peer is just a potential security risk.


this is also worth a discussion

arndt-s · 2026-01-21T12:27:12Z

pkg/agent/broker/endpoints.go

+	)
+
+	e.registerBrokerAPI(server)
+	reflection.Register(server)


Any objections in having it here? I don't see a drawback and could help brokers that don't want to know the proto?

arndt-s · 2026-01-21T12:27:36Z

pkg/agent/broker/endpoints.go

+		// I suppose technically it's not possible on the admin API to encounter this, but considering that
+		// the SPIFFE Broker Endpoint may be offered over the network in the future I think it's better to
+		// enforce this here.
+		if id.TrustDomain() != trustDomain {


I added a configuration sanity check here. Any objections?

Dimss · 2026-02-03T12:21:59Z

pkg/agent/broker/endpoints.go

+	// TODO(arndt): Delegated Identity API allows to be served without any authorized peer.
+	// I think it's better to fail as it's a misconfiguration and having that socket up
+	// without any authorized peer is just a potential security risk.
+	if len(e.c.AuthorizedDelegates) == 0 {


@arndt-s
This means the authorized delegates SpiffeIDs must be well known and configured ahead the deployment happens.
The problem is that when deploying SPIRE on K8s/OCP you not necessary know what they are.
Let's take Istio as an example.
First user deployed SPIRE, next deploys Istio.
The SPIFFE IDs are created dynamically based on the ClusterSPIFFEID CRs
With if len(e.c.AuthorizedDelegates) == 0 the Spire agent won't become healthy until relevant Spiffe ID is created and the Spire-Agent config map being updated.

I think we should disable this constraint, or at least make it optional.

Generally you should be able to determine what SPIFFE IDs your workload is going to receive ahead of time. For example in k8s most of the time this is defined from namespace and service account names, which I imagine you have some control over.

It's possible to include more randomised information in there, e.g. pod uid in k8s, but I don't think that's particularly common. If that's the case, the policy specified here through this authorised delegates list could get some support for wildcarding.

Before doing that we'd like to see that there is an actually need for it, so if you have a use case where that's necessary let us know. Either way, that's not something that needs to be handled by this PR.

…ker_endpoint_and_api

arndt-s · 2026-02-16T10:06:27Z

pkg/agent/attestor/workload/workload.go

-	if err != nil {
-		return nil, fmt.Errorf("workload attestor %q failed: %w", a.Name(), err)
-	}
+	// // The agent health check currently exercises the Workload API. Since this


Can broker use agent PID? I'd like to block that? What if it uses the pod UID of the agent?

TODO for myself to find a solution so that workload.go get's to know it's itself without knowing the details of the reference.

arndt-s · 2026-02-16T10:08:00Z

Dockerfile

How do others make images with custom api & plugin packages?

arndt-s · 2026-02-17T16:56:00Z

Things to discuss:

Workload Attestor v2 interface
- v1 <-> v2 compatability
- proto Any
Broker Endpoint Socket
- authn (bundle & svid source from agent <-> server comms)
  @sorindumitru mentioned that there could be an API on the server that allows both. Also to check key manager and locking during rotation.
- authz (re-using admin socket allowlist)
- -> do dedicated allowlist
- gRPC reflection API
Windows support

wip: implement broker api

efc7313

Signed-off-by: arndt-s <17650715+arndt-s@users.noreply.github.com>

arndt-s commented Jan 21, 2026

View reviewed changes

add bundles to response, change rpc names

ba52838

Dimss reviewed Feb 3, 2026

View reviewed changes

arndt-s added 3 commits February 16, 2026 09:39

wip

237083e

Merge remote-tracking branch 'upstream/main' into arndt/implement_bro…

3ef6fbb

…ker_endpoint_and_api

use sdk repos, fix bugs

2e67e90

arndt-s commented Feb 16, 2026

View reviewed changes

Dockerfile

Copy link

Member Author

arndt-s Feb 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do others make images with custom api & plugin packages?

This was referenced Feb 16, 2026

Add workloadattestor v2 spiffe/spire-plugin-sdk#71

Open

Add Broker API spiffe/spire-api-sdk#92

Open

Conversation

arndt-s commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arndt-s left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arndt-s commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

arndt-s commented Jan 21, 2026 •

edited

Loading

arndt-s commented Feb 17, 2026 •

edited

Loading