Allow users authenticated with an API keys to manage alerting rules #152140
Comments
mikecote
added
blocked
Team:ResponseOps
|
Pinging @elastic/response-ops (Team:ResponseOps) |
github-project-automation
bot
moved this to Awaiting Triage
in AppEx: ResponseOps - Execution & Connectors
ersin-erdal
moved this from Awaiting Triage
to Todo
in AppEx: ResponseOps - Execution & Connectors
mikecote
moved this from Todo
to Blocked / On hold
in AppEx: ResponseOps - Execution & Connectors
mikecote
moved this from Blocked / On hold
to Todo
in AppEx: ResponseOps - Execution & Connectors
|
Removing the blocked label now that #152116 has merged. |
I think the implication is that we'll need to be able to identify API keys in the rule SO that we manage vs those that we don't. Presumably via an additional flag in the SO. Or maybe metadata in the API key (seems fragile to me though). Interesting that this may be a stepping stone to #106878 - specifically, we'd be in a position where we could support explicit API keys users create and supply for the rules, as well as the implicit ones we create today. Would still require a lot of work - mainly UX-wise I think, but getting closer! |
doakalexi
moved this from Todo
to In Progress
in AppEx: ResponseOps - Execution & Connectors
doakalexi
moved this from In Progress
to In Review
in AppEx: ResponseOps - Execution & Connectors
github-project-automation
bot
moved this from In Review
to Done
in AppEx: ResponseOps - Execution & Connectors
…erting rules (#154189) Resolves #152140 ## Summary Updates the following functions in the Rules Client to re-use the API key in context and avoid having the system invalidate them when no longer in use: - bulk_delete - bulk_edit - clone - create - delete - update - update_api_key Also adds a new field to the rule SO to help determine when whether an api key was created by a user or created by us. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### To verify - Follow these [instructions](https://www.elastic.co/guide/en/kibana/master/api-keys.html#create-api-key) to create an api key. Make sure to copy your api key - Run the following ``` curl -X POST "http://localhost:5601/api/alerting/rule/" -H 'Authorization: ApiKey ${API_KEY}' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d' { "rule_type_id": "example.pattern", "name": "pattern", "schedule": { "interval": "5s" }, "actions": [ ], "consumer": "alerts", "tags": [], "notify_when": "onActionGroupChange", "params": { "patterns": { "instA": " a - - a " } } }' ``` - Verify that the request returns a rule with`"api_key_created_by_user":true` - Try this with the other rules clients functions listed above to verify that you can manage alerting rules when authenticated with an api key - Verify that `"api_key_created_by_user":false` when you remove the api key header and add `-u ${USERNAME}:${PASSWORD}` to authenticate
|
@pkobziak please have a look |
|
@MikePaquette This case is reported by DT Security Team, this behavior is quite problematic for them since many people may be using API to create rules. when keys are invalidated rules should work independently from the user key. |
As a user, I would like to authenticate with an API key and be able to interact with the alerting APIs (ex: create, update, delete rules).
It is currently not possible because the system attempts to create an API key from an existing API key (elastic/elasticsearch#52244 and elastic/elasticsearch#59304). Instead, we should change our code to re-use the API key in context (from the authentication) and avoid having the system invalidate them when no longer in use.
To make this happen, we will need the following:
authentication_typeof the logged in user (https://github.com/watson/kibana/blob/af7f42cfb7b23a1bba691d060581fcd216429632/x-pack/plugins/security/common/model/authenticated_user.ts#L49-L54) and apply special logic when it'sapi_key.authentication_typeisapi_key(Allow API Key components to be extracted from the currentKibanaRequest#152116)authentication_typeisapi_keyinstead of generating a new API key.Addingblockedlabel until #152116 is complete.The text was updated successfully, but these errors were encountered: