Rules API Key

Elastic Stack Kibana
1

Hi all,

the Kibana Alerting doc (Alerting set up | Kibana Guide [8.3] | Elastic) says rules are authorized using an API Key created internally with the same privileges as the user creating/updating the rule. I wonder if it is possible to use a custom API Key to perform the same task or, at least, modify the automatically created API Key to inject metadata.

Thank you,
R.

2

Hi @robdiluca ,

Welcome to the community!

This isn't currently possible due to a security restriction where by we have to link a specific user to the source of every API Key used by a rule - this is in order to ensure sufficient auditing of activity by rules.
We're exploring ways to make this easier for users (such as generating an API Key from your user with a subset of your privileges), but this is not yet scoped out sufficiently.

The workaround I could recommend (which other customers have used) is to create a dedicated user with the privileges you'd like to enforce on a rule and then use that dedicated user to create and manage all of your rules.

I hope that workaround is good enough for your needs.
If this workaround is insufficient, I suggest following this issue in which we're tracking the need that you have expressed. I truly hope we'll be able to address this in the near future, but I can't make any promises.

Cheers

3

Hi @gmmorris ,

thank you for your reply. Alternatively, wouldn't it be possible to "copy" role's metadata field associated with the user managing the rule in the api key's metadata field automatically created?

4

In practice that's more or less what happens when a user creates/edits a rule.

What it sounds like you're asking for is the ability to do so manually so that you can modify the privileges that are applied to the rule, right? This isn't currently possible both from a UX perspective, and from a security perspective, but as I said we are considering adding these abilities (it isn't as simple as it sounds, as usual :wink: ).

Feel free to add a comment on that issue with your explicit use case and requirement. I can't promise we'll deliver what you ask, but I can promise we'll consider your feedback when designing our solution (as you might imagine we have a wide range of customers asking for related, but different, things; we have to weigh them all into our final approach).

5

Well, actually what I'm interested in is the ability to share a kind of property (a key-value pair) between the user and his api keys, not changing the api key privileges. I thought I could add this piece of information in the api key metadata. Then I would process this property in a ingest pipeline through the set_security_user processor.

6

oh, interesting.
So you want to use the processor to inject metadata into documents that the rule is indexing when an alert is active, based on the rule author?

7

Exactly! Suppose I have a rule with an indexing action, I'd like to process documents through an ingest pipeline according to the api_key.metadata field. Of course, that metadata should be provided explicitly (using a custom API Key in the Kibana rule) or implicitly (from the user's role, for example).
Do you have any suggestion on how could I achieve something like that or another way to do something similar?

Thank you for your help.

8

@robdiluca do you mind elaborating on what your end goal is? It sounds like you're trying to get some custom fields specified on a document that is created in a custom index. What fields are you trying to populate in which index and why do the need to come from the API Key?

9

Hi @Brandon_Kobel , thank you for the reply. My end goal is trying to achieve something similar to an application privilege. With that feature, applications can store their own privilege models in ES roles. In this case, given a document indexed by the action of an alert, I'd like to know if the used API Key is authorized to index documents related to a particular application. That is, I'd like avoiding that a rule could write documents related to another application.

As an example, consider an indexing action for a certain rule indexing a document such as:

{
	“application”: “test-application-a”
	“custom-field”: “logs threshold exceeded”
}

and another rule indexing a document such as:

{
	“application”: “test-application-b”
	“custom-field”: “uptime alarm”
}

Given this situation, I'd like to enforce that the API Key for the first rule is authorized to index only documents having {“application”: “test-application-a”} and the API Key for the second rule to be able to index documents having {“application”: “test-application-b”} .

Please, tell me if this explanation is not clear or if you could suggest something to implement something like this.

Thank you.

10

Thank you for the additional explanation, @robdiluca, it was incredibly helpful.

There are a couple options that I can think of which wouldn't require Kibana or Elasticsearch to add any features, but there's also a longer term option that would rely on us adding an Elasticsearch feature that others have requested as well. We haven't had similar requests to forward metadata from the API Key in such a manner that it can be used by an ingest pipeline to enforce custom authorization logic, so it's a rather unlikely long-term option.

1) Elasticsearch index per application (possible without changes)

If we were able to create an Elasticsearch index per application, you could only grant certain users access to write documents to specific indices. This would achieve the same semantics that you're looking for when all documents are written to the same index with different field values per application. If we only have a few applications, this approach shouldn't have any significant downside. If there are a large number of applications, this approach would contribute to "mappings explosions" via over-sharding.

2) Create a webhook that writes documents to Elasticsearch (possible without changes)

If you were to create a webhook, you could create a Kibana connector with pre-configured credentials that only works with specific applications. Since Kibana connectors are space-specific, this would allow you to segment which users can have access to write documents to which indices.

3) Change Elasticsearch's document-level security to work with writes (requires changes)
Currently, Elasticsearch's document-level security only works with read operations, it doesn't work with writes. As a result, changes would have to be made to Elasticsearch's implementation of DLS to make it a suitable solution here.

11

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.