Restricting Seq API key read access to events matching specific properties

[esp0]

Hi,

We’re using Seq extensively and are currently exploring how to expose a subset of events through an internal service using the Seq.Api NuGet package.

Our Seq server is configured with Microsoft Entra ID for authentication, which our employees use to access the Seq UI. This works well for interactive access.

Separately, we have a backend service that queries Seq using the Seq.Api package. The purpose of this service is to show partners a list of requests they have made to our public API (after they log in to our system).

What we would like to achieve is:

• Create an API key used by our backend service

• Restrict that key so it can only read events that match certain criteria, such as:

  • Application = "PartnerApi"
  • a specific event type

The goal is to ensure the API key cannot read other events stored in Seq, since the instance contains many unrelated logs.

My questions:

1. Is it possible to restrict API key read permissions based on event properties?
2. If so, what is the recommended way to configure this (signals, filters, permissions, or something else)?
3. If property-level restrictions are not supported for API keys, what is the recommended pattern for safely exposing a subset of events through Seq.Api?

[nblumhardt]

Hi @esp0, thanks for your message!

I think the best approach to this would be to use a plug-in Seq app to replicate the events in question into a separate (classic SQL database) table for the API to consume.

For example, you could use https://github.com/datalust/seq-app-httprequest to push events matching the event type/Application = 'PartnerApi' to an endpoint on the internal service that would write it to the service's own local database.

Your query about locking API keys down to this does make sense, but a lot of scenarios in this general area are covered by pushing streams of events out from Seq, and those that aren't we're planning to cover using a slightly different "Projects" mechanism in the future, so the push approach should set you up for the best chances of long-term success.

The alternative today would be to create a "service" user in Entra ID, log in interactively using that account to create a user-specific API key, and apply a "View filter" to the user in Seq's Settings > User screen. It's a bit clunky, but should achieve what you're after: API keys belonging users with view filters applied inherit the view filter.

Let me know if either option will do the job.

Best regards,
Nick

[esp0]

Hi Nick,

Thanks for the suggestions.

Both approaches could work for us. The push-based approach with a Seq app writing the relevant events to a separate database is definitely an option.

The service user approach would probably also work, but the downside for us is that it requires provisioning an additional Entra ID user purely for this integration.

Ideally, what we were hoping for was a way for an administrator to create API keys that are restricted by a filter (similar to view filters) without the key needing to belong to an Entra-backed user. For example, allowing an administrator to create a user API key on behalf of a local Seq user.

That would avoid needing a dedicated Entra user just for this purpose.

Is anything like that possible today, or is the service user + view filter approach the only option?

Thanks again for the help!

[nblumhardt]

Hi Espen,

API keys can't explicitly carry view filters today; it's something we could consider down the track, but it's unlikey to make the list for at least the next few releases, unfortunately.

Best regards,
Nick