Support SPIFFE IDs derived from Kubernetes object properties

[matheuscscp]

Follow up for #7074

In #7074 we plan to tighten the security of SVIDs acquired by brokers through KubernetesObjectReference. This tightening will require operators to add Kubernetes RBAC rules to their cluster that is attested by the Broker API to allow for specific brokers to have access to act on behalf of specific Kubernetes objects. In other words, additional complexity and configuration steps.

In a future release, we could facilitate the setup by providing an opt-in feature where SPIFFE IDs can be derived from the Kubernetes object properties that are currently made available at the moment when selectors are emitted for the object (this new feature would effectively be an alternative to the traditional selector-based identification process).

Something like: spiffe://<td>/kubernetes/{group}/{plural}/{namespace}/{name}

The above starts from the same fields required by the KubernetesObjectReference. However, users could want different things, e.g. including the object's UID. So we could instead provide a way to specify a Go template instead, or a CEL expression, where the Kubernetes object is made available e.g. .Obj (Go template) or obj CEL expression. In this case, the above could be the default template/expression.

[sorindumitru]

Thanks for opening this issue @matheuscscp. This has been brought up before and we've always considered that it's not good alignment with the project security posture. Since more people are requisition this, I know @kfox1111 also mentioned it for spire-identity-exchange, maybe it's time to look a bit more into what it would take.

Some issues that were brought up:

• Collision with internal SPIFFE IDs used by spire, e.g. spiffe://<td>/spire/agent/...
• Collision with SPIFFE IDs from other entries, including things like admin or downstream entries which have more privileges than other SPIFFE IDs.

[amartinezfayo]

I think this lands on a few of the root decisions behind how registration works in SPIRE and the templating is really only the surface of it.

The registration mechanism rests on three choices that are load-bearing for the threat model. Registration is an explicit, deny-by-default allowlist: an identity exists only because someone with authority created an entry for it. The datastore is the single authority over the ID namespace, so there is exactly one writer deciding which paths exist. And the SPIFFE ID is administratively assigned and decoupled from the workload's attributes, while selectors are matched and verified out-of-band. The ID is assigned, the selectors are proven. Deriving the ID from object properties at mint time relaxes all three at once, which is why this keeps surfacing concerns from different directions.

For context, we already have templated derivation in spire-controller-manager (the spiffeIDTemplate on ClusterSPIFFEID), but it preserves the invariant: the template renders into a real registration entry that goes through the normal server-side validation, deny-by-default, and the audited datastore record. The thing worth examining is what we would be giving up by doing the derivation at attestation/mint time without that explicit entry.

On @sorindumitru's collision point, I think it splits into two cases. Collision with spire-internal IDs we already cover: the server rejects any workload entry under the reserved /spire/ namespace, so a derived ID can't alias spiffe://<td>/spire/agent/... as long as it flows through that validation. The case that isn't handled today is collision with operator-registered entries: admin and downstream are flags on ordinary entries, so a privileged identity can live at an arbitrary path in the general namespace, and nothing prevents a derived spiffe://<td>/payments from landing on a manually registered admin entry. More broadly, this is the single-authority decision being relaxed: explicit entries and a derivation function become two independent writers into one path namespace, so collisions are an expected outcome rather than an edge case.

There's also a dynamic version of the same concern. Because the ID is a function of object data, mutable fields (labels, annotations, spec, status) let whoever can patch the object influence the resulting ID, and field values concatenated into the path could inject separators or produce non-canonical forms that we and a consumer normalize differently. So the safety depends heavily on which inputs the template is allowed to read and on how the rendered output is validated.

Finally, there's an interaction with the authorization being discussed in #7074 worth flagging, independent of how that check ends up being designed. The intent there is to authorize whether a broker may act on a given object, but the template computes the identity from that same object, so if the derivation reads properties the authorization didn't reason about, a broker authorized for X could end up with Y's identity. The authorization and the derivation would need to be reasoning about the same set of properties for that gap to close.

[matheuscscp]

Thanks @sorindumitru and @amartinezfayo for considering the request.

I think the conflict problem is easy to solve:

1. The template is chosen by the SPIRE administrator/operator. So "The case that isn't handled today is collision with operator-registered entries" is not a real problem. They won't choose inconsistent configuration.
2. Instead of providing defaults, the feature configuration can require both things to be specified by the SPIRE admin/operator:
   a. The template
   b. A prefix namespace e.g. /kubernetes/ that SPIRE can validate against reserved namespaces e.g. reject /spire/

Even if the feature will have no defaults, the docs can suggest good choices for these required inputs.

[matheuscscp]

There's also a dynamic version of the same concern. Because the ID is a function of object data, mutable fields (labels, annotations, spec, status) let whoever can patch the object influence the resulting ID, and field values concatenated into the path could inject separators or produce non-canonical forms that we and a consumer normalize differently.

This is in control of the SPIRE operator. I honestly don't picture people adding Kubernetes labels to the SPIFFE ID.

The main use case I see for this feature is this template:

spiffe://<td>/kubernetes/{group}/{plural}/{namespace}/{name}

These four properties are immutable across the life of a Kubernetes object. Also, they are the object identity inside the cluster. So if a random tenant can create a resource in a random namespace, it doesn't matter that a SPIFFE ID will be issued for that object because it carries exactly the object identity/reference in it. That is exactly what is being asked: allowing Kubernetes object identities to be their own SPIFFE identities. To disambiguate between identical objects in different clusters the operator can tune the <td> to include the cluster name/ID, or the prefix namespace e.g. /kubernetes-prod-1/.

[matheuscscp]

We can probably reduce the scope fed to the Go template / CEL expression to just the SPIFFE KubernetesObjectReference, and not the entire Kubernetes object like proposed initially. This introduces a number of guarantees, e.g. changing labels or annotations is no longer a concern. The SPIFFE KubernetesObjectReference looks like this:

{
  "type": {
    "group": "core",
    "plural": "pods"
  },
  "key": {
    "name": "some-app-xyzfg",
    "namespace": "apps"
  },
  "uid": "2945a584-0811-4266-b8ac-ee10eb3255d3"
}

---

Better yet, to introduce even more guarantees we could avoid a template / expression and build specific patterns that could be useful, and let it be expressed in the configuration through an enum. And since these opinionated templates are hardcoded, we can let them use fields from the entire Kubernetes object instead of just the SPIFFE KubernetesObjectReference (e.g. useful for including .kind, the SPIFFE reference has only the plural).

The fields above uniquely define "who is the object inside the cluster", so it makes sense to derive SPIFFE IDs from them. With purpose-built templates we define specific mappings from one space to another, and the "which cluster" component can be expressed as explained in my previous comment.

So the configuration for this feature would look like this (I'm writing this by hand and I don't have HCL syntax fresh in my head):

{
  "path_prefix": "/kubernetes-prod-1",
  "id_strategy": "GroupKindNamespaceName"
}

Interesting use cases for id_strategy:

• GroupKindNamespaceName: Canonical object reference users know from the top of their heads, dealing with YAML in their GitOps repo everyday. These four fields are directly visible in a Kubernetes YAML manifest and uniquely represent an object in a cluster. It's the "object address" users know without thinking too much.
• GroupPluralNamespaceName: Plural is always 1:1 with kind, but plural is lowercase (e.g. replicasets) while kind is singular with CamelCase (e.g. ReplicaSet). More appropriate for a URL, like a SPIFFE ID.
• GroupPluralNamespace: Soft multi-tenancy. Some namespaces belong to a tenant. The object name inside the namespace does not matter, access is granted by type+namespace.
• GroupPlural: Hard multi-tenancy. The entire cluster belongs to a tenant. No matter the object, if it's a Flux object then access can be granted.
• GroupNamespace: Soft multi-tenancy with coarse-grained typing: I don't care about which specific Flux source-controller CRD it is. I Just care that it's source-controller and not notification-controller.
• Group: Hard multi-tenancy with coarse-grained typing.
• GroupPluralUID: This is GroupKindNamespaceName with level 1 of security paranoia: Don't grant access if the object gets recreated! If someone deletes the kubernetes corev1.Service in the default namespace they cannot be well intentioned 👀
• GroupPluralNamespaceNameUID: Level 2 of security paranoia: "Okay, let me check exactly who you are...!"

Implicit rule: Cluster-scoped objects (i.e. k8s objects without namespace) don't get a namespace. The enum alternative is particularly good at this. The template alternative would require two templates in the configuration, one for namespaced objects and one for cluster-scoped ones.

Respective example SPIFFE IDs for the enum options defined above:

• spiffe://<td>/kubernetes-prod-1/source.toolkit.fluxcd.io/OCIRepository/flux-system/flux-system
• spiffe://<td>/kubernetes-prod-1/source.toolkit.fluxcd.io/ocirepositories/flux-system/flux-system
• spiffe://<td>/kubernetes-prod-1/source.toolkit.fluxcd.io/ocirepositories/apps
• spiffe://<td>/kubernetes-prod-1/source.toolkit.fluxcd.io/ocirepositories
• spiffe://<td>/kubernetes-prod-1/source.toolkit.fluxcd.io/apps
• spiffe://<td>/kubernetes-prod-1/source.toolkit.fluxcd.io
• spiffe://<td>/kubernetes-prod-1/core/services/1d629586-8144-4063-aa12-f14b4cf3dfd3
• spiffe://<td>/kubernetes-prod-1/core/services/default/kubernetes/1d629586-8144-4063-aa12-f14b4cf3dfd3

[amartinezfayo]

Thanks @matheuscscp.

reduce the scope fed to the Go template / CEL expression to just the SPIFFE KubernetesObjectReference [...] changing labels or annotations is no longer a concern

This narrowing resolves most of what I raised. With only immutable identity fields in scope the mutable-field surface goes away, and the enum variant lets SPIRE own the rendering so it can guarantee a canonical SPIFFE ID, which removes the injection and non-canonical concerns. It also happens to close the gap I flagged with #7074, since the derivation and the authorization would then be reasoning about the same object identity rather than about different properties.

They won't choose inconsistent configuration.

The prefix addresses the collision concern when SPIRE enforces it rather than relying on operators keeping their configuration consistent. If SPIRE confines derived IDs to the configured prefix and prevents that prefix from overlapping with manually registered entries, the single-authority property is restored inside the prefix, where derivation owns that subtree and explicit registration owns the rest. That turns "they won't choose inconsistent configuration" into "they cannot", which is the guarantee I would want on the minting path rather than relying on discipline. What do you think about having SPIRE enforce the prefix this way?

it doesn't matter that a SPIFFE ID will be issued for that object because it carries exactly the object identity/reference in it. That is exactly what is being asked: allowing Kubernetes object identities to be their own SPIFFE identities.

I agree this is the goal, and I think it is also the core of the security posture question @sorindumitru raised at the top. With the reduced scope the derived ID carries the same object identity the attestation already establishes, so it adds little new authority as long as the #7074 authorization soundly gates who may act on that object. What changes regardless is that deny-by-default becomes allow-by-rule. Today an identity exists only because someone created an entry for it, and here every attestable object automatically becomes an identity, so the per-identity decision point and the audit record go away. The UID strategies you list handle the delete-and-recreate angle, and strategies like Group and GroupPlural mean one identity stands for a whole class, so whoever can create any matching object can obtain it.

I'm thinking that both could be recovered without bringing back the full registration step, and I would want them together rather than either alone. To restore a gate in front of derivation, the derivation config could carry an eligibility filter that decides which objects participate at all, scoped by group or namespace and defaulting to none, so derivation stays deny-by-default by class even if it is not per-identity. This is close to how spire-controller-manager already scopes which objects it targets before creating entries. To restore the audit trail, each derived mint could emit an audit event with the object reference, the resulting ID, and the requesting broker, so it does not disappear just because there is no datastore entry.

[matheuscscp]

What do you think about having SPIRE enforce the prefix this way?

It depends on what "enforcing" means. Existing, manually-registered entries that have SPIFFE IDs matching the formats I'm suggesting above could become a problem the moment the feature is enabled in SPIRE's configuration. For example, a SPIRE user could be using an entry where the selector matches the pod's k8s ServiceAccount, and that ServiceAccount represents a k8s Deployment, which in turn is a good use case for the formats I'm suggesting above (hence such users could actually be using one of them or similar). For such users, there are two problems:

• Deleting the entry before SPIRE restarts with the new configuration may represent causing downtime in k8s workloads currently consuming the Workload API.
• If enforcing the prefix means SPIRE will freak out with previously-existing SPIRE entries with SPIFFE IDs matching the formats above, then deleting the entry after SPIRE restarts with the new configuration may also represent causing downtime.
• Enforcing the prefix meaning SPIRE will only reject newer entry registrations that hurt the rule also means SPIRE is allowed to remain in an inconsistent state.

So I think rejecting SPIFFE IDs in manual entries matching the path_prefix is almost a breaking change: a guaranteed headache when enabling the feature (if you don't want to change your SPIFFE IDs i.e. you want a path_prefix that is already the one you are using via manually-registered entries). I think I would allow this harsh requirement only as an opt-in behavior, where the user will prepare for a complex migration, which would require changing the configuration on the relying parties to flip to the new SPIFFE ID namespace. The feature should default to being lenient with SPIFFE ID collisions between the derived IDs and the entries.

---

About the eligibility filter, yes, we can implement one. In this case I would lean towards Kubernetes-native filters e.g. metav1.LabelSelector, api_group, kind, name, namespace. Similar to .spec.inputsFrom in Flux Operator's ResourceSet CRD:

https://fluxoperator.dev/docs/crd/resourceset/#inputs-configuration

But with the namespace field in addition.

I think an eligibility filter is actually also necessary to solve the pod problem. An existing typical use case for SPIRE entries is matching a Kubernetes ServiceAccount (a SPIRE selector emitted from Pod.spec.serviceAccountName) and choosing a SPIFFE ID that actually represents the k8s Deployment all the pods belong to. Imagine a pub/sub consumer group storing messages in object storage. You don't want to match pods from this consumer group individually, you'd rather match the group. This means we

---

Config proposal (updated after my next comment below):

kubernetes_spiffe_id = {
  path_prefix = "/kubernetes-prod-us" # or just "/kubernetes".
  reject_new_entries_with_path_prefix = true # optional. default: false.

  # the first entry matching the Kubernetes object wins. every object gets at most one SPIFFE ID!

  # the feature has special handling for core workload types, i.e. apps/Deployment,
  # apps/ReplicaSet, apps/StatefulSet, apps/DaemonSet, batch/CronJob, batch/Job,
  # i.e. all the well-known Pod owners. entries matching these workload types
  # will elect both the explicit object type (e.g. Deployment, StatefulSet, etc.)
  # and Pods matching them by following up the Kubernetes owner references.

  entries = [
    # example: match a very specific Deployment.
    {
      id_template = "/payments-service"

      filter = {
        api_group = "apps" # accepts wildcard `*`. required.
        kind = "Deployment" # accepts wildcard `*`. required.
        namespace = "apps" # accepts wildcard `*`. required.
        name = "payments-service" # does not accept wildcard. optional. mut. exclusive with selector.

        # optional. mut. exclusive with name.
        selector = {
          match_labels = {
            "app" = "payments-service"
          }
          match_expressions = [
            {
              key = "app"
              operator = "In"
              values = ["nginx", "apache"]
            },
          ]
        }
      }
    },

    # example: match all the Flux objects reconciled by source-controller in the flux-system namespace.
    {
      id_template = "/flux-system-sources/{plural}/{name}"

      filter = {
        api_group = "source.toolkit.fluxcd.io"
        kind = "*"
        namespace = "flux-system"
      }
    }

    # example: match every object in the cluster.
    {
      id_strategy = "group_plural_namespace_name"

      filter = {
        api_group = "*"
        kind = "*"
        namespace = "*"
      }
    }
  ]
}

[matheuscscp]

Enum-based ID strategies are cool but also very opinionated.

The entries above could have id_strategy and id_template, mutually exclusive, exactly one set. id_template uses a simple template syntex e.g. /fluxcd-sources/{plural}/{namespace}/{name} where the available fields are the restricted ones discussed previously (immutable, part of the object ref. / key).

[c4rlo]

See also #5937.

[matheuscscp]

Thanks for bringing that up @c4rlo! Yeah, it makes total sense that templated IDs have use cases in more systems...

Maybe a platform-agnostic solution could be a better feature. To make the filtering side platform-agnostic we could use the existing selector system, potentially making it more flexible matching-wise (e.g. so that I could have a single rule matching all objects in a Kubernetes cluster, like in my config example above). The remaining problem is what @amartinezfayo has highlighted in this thread: allowing arbitrary selectors to be used for composing the ID makes it unstable. This means a generic feature would need the introduction of a new "bag of stable identification values" a workload / object would need to expose in order to benefit from a dynamically generated SPIFFE ID. For Kubernetes objects that bag of stable identification values is clear:

• group
• plural
• kind
• namespace (if the resource type is namespaced i.e. not cluster-scoped)
• name
• uid

I'm not sure about other systems, but as a long as a system can express the identification of their workloads / objects in a stable way like requested by @amartinezfayo, that system could be supported for this feature.

If there's interest in implementing this feature in a platform-agnostic way where platforms can be added gradually as soon as they meet the requirements, then it is possible that now we are here just talking about making some improvements in the existing entry system. Make it:

• support simple templates inflated by a map[string]string containing values that identify the workload / object in a stable way.
• flexible enough to match an entire space of workloads / objects when they can satisfyingly express the identity space the SPIRE user is looking for (e.g. I want all the objects in my Kubernetes cluster to have unique SPIFFE IDs and I want to express this with a single entry).

About the dedicated code for Kubernetes core workload types I mentioned above, I realize now that selectors are enough, we don't need that (that much is obvious, that's how all Kubernetes + SPIRE users already doing things for a long time).