Skip to content

Consider allowing query strings in SPIFFE IDs #88

Open
@jkanywhere

Description

Hello SPIFFE team,

I have a use case which would benefit from using query strings in SPIFFE IDs, a use currently forbidden by The SPIFFE Identity and Verifiable Identity Document standard. ("Valid SPIFFE IDs ... MUST NOT include a query ... component.")

Our services have [at least] two attributes

  • application id (app) - Used when services have multiple entry points or execution modes, such as web application or batch processing. Also used when the same service runs with a variety of different configurations such as a log processor ingesting from two different streams.
  • run time environment (env) - Used to indicate production vs staging. Production takes customer traffic, staging does not.

Both app and env are used to make authorization decisions: staging services can only write to other staging services; different applications should be able to read only from their corresponding input source.

(A similar example is given in the 2.2 Path section using service account and namespace.)

Adding app and env to URI path implies a hierarchical relationship when there is none:

  • Do applications live inside an environment, for example
    spiffe://k8s-west.example.com/service/foo/env/staging/app/streaming
  • or, is environment a sub-component of an application?
    spiffe://k8s-west.example.com/service/foo/app/streaming/env/staging

Neither is strictly true, app and env are orthogonal concepts. (The problem is multiplied when adding a third attribute.)

To highlight the key value nature of the data and we could use =, part of "sub-delims" reserved by RFC 3986, instead of /:
spiffe://k8s-west.example.com/service/foo/env=staging/app=streaming
spiffe://k8s-west.example.com/service/foo/app=streaming/env=staging

We can of course build application logic that would treat these two URIs as identical, however the naive approach would treat them differently and most developers are used to treating paths as hierarchical, regardless of separator.

On the other hand, because most web application developers and url parsing libraries are already familiar with query string as an unordered maps. It is more clear that
spiffe://k8s-west.example.com/service/foo?env=staging&app=streaming
is identical to
spiffe://k8s-west.example.com/service/foo?app=streaming&env=staging.

How would you recommend to handle this situation?
What are your reasons for excluding query component from SPIFFE URIs? (Perhaps trying to add metadata to identity is a mistake in the first place.)
Are you open to expanding the standard?

Thank you.

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions