-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable creating alert client instances when ESO plugin is using an ephemeral encryption key #56676
Disable creating alert client instances when ESO plugin is using an ephemeral encryption key #56676
Conversation
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize it's not much of a concern in 7.6, but wouldn't we want to disable the creation of actions/connectors as well if an ephemeral key is used?
I agree, I was thinking of doing those in a separate PR and only backport this PR (alert APIs) into 7.6? Happy to backport both otherwise. I will keep the main GH issue #56420 open until both API sets are fixed and backported properly. |
@@ -119,6 +121,7 @@ export class Plugin { | |||
taskManager: plugins.taskManager, | |||
securityPluginSetup: plugins.security, | |||
encryptedSavedObjectsPlugin: plugins.encryptedSavedObjects, | |||
isESOUsingEphemeralEncryptionKey: this.isESOUsingEphemeralEncryptionKey!, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move the logic from the alerts client and move it into getAlertsClientWithRequest
function below? 🤔 There's also the alerts client factory that could handle it.
This would mean we throw this error at a higher level with more ways around it but a lot less code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like the answer would be yes. Unless the encryption key can be set in the config "live" via the NP plugin live config bits. In that case, we'd need to rebuild the alerts client at the same time, at which point it would be happy with the key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seconded 👍
That makes more sense to me too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one holdback I have is that we expose the AlertsClient class (https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/alerting/index.ts#L14) so others who use the class directly wouldn't be protected anymore. 🤔 We should probably just expose the interface instead of the class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ to pulling it up to getAlertsClientWithRequest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, exposing an interface would be better, eg we could have a "disabled" version of the class which just threw errors for all the API calls, which we returned in this case, instead of the "real" one.
But it also makes me wonder if there are some APIs we should actually allow. find()
and get()
seem ok to me, and I'm wondering if that would be useful to have available in this case. Probably doesn't matter, since you can't really do anything else at this point anyway without fixing the encryption key config ...
…ephemeral encryption key
bce4018
to
b34fa68
Compare
@gmmorris @peterschretlen @pmuellr let me know your thoughts. I've made the changes based on the discussion we've had here: #56676 (comment). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Initially, this felt kind of "blunt", I guess I was thinking we'd return an alert client that implemented all it's methods as things that threw the exception, instead of throwing when trying to get the alert client. But after seeing this, I think it's probably better, as it let's a plugin using alerting to be able to make the determination up front, instead of at every point they use the alert client. I guess we'll find out.
Was looking at our routes, and I suspect we will want them enhanced. Eg
kibana/x-pack/legacy/plugins/alerting/server/routes/create.ts
Lines 68 to 71 in 885b79e
async handler(request: ScheduleRequest) { | |
const alertsClient = request.getAlertsClient!(); | |
return await alertsClient.create({ data: request.payload }); | |
}, |
Won't it throw something in that reques.getAlertsClient!()
call now, that it wouldn't before? I think the result would be that you'd get a 400 "invalid request" kind of result, but it would be nice to actually indicate what the error was. Or maybe since it's security-related, it would be best NOT to. Worth noodling over a bit (separate issue), I think it's certainly survivable as-is for now.
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 Tested it out with the management UI and detection engine and confirmed you can't create or list alerts. Dev mode works as before with the 'aaaaa....' key, so dev experience is unchanged which is great.
@pmuellr thanks for the review! I will create a follow up issue for your comments: #56676 (review). |
…ephemeral encryption key (elastic#56676)
* master: (23 commits) Properly handle password change for users authenticated with provider other than `basic`. (elastic#55206) Improve pull request template proposal (elastic#56756) Only change handlers as the element changes (elastic#56782) [SIEM][Detection Engine] Final final rule changes (elastic#56806) [SIEM][Detection Engine] critical blocker, wrong ilm policy, need to match beats ilm policy Move ui/agg_types in to shim data plugin (elastic#56353) [SIEM] Fixes Signals count spinner (elastic#56797) [docs] Update upgrade version path (elastic#56658) [Canvas] Use unique Id for Canvas Embeddables (elastic#56783) [Rollups] Adjust max width for job detail panel (elastic#56674) Prevent http client from converting our form data (elastic#56772) Disable creating alerts client instances when ESO plugin is using an ephemeral encryption key (elastic#56676) Bumps terser-webpack-plugin to 2.3.4 (elastic#56662) Advanced settings component registry ⇒ kibana platform plugin (elastic#55940) [Endpoint] EMT-67: add kql support for endpoint list (elastic#56328) Implement UI for Create Alert form (elastic#55232) Fix: Filter pill base coloring (elastic#56761) fix open close signal on detail page (elastic#56757) [Search service] Move loadingCount to sync search strategy (elastic#56335) Rollup TSVB integration: Add test and fix warning text (elastic#56639) ...
Resolves the alerting portion of #56420.
In this PR, the alerts client will throw an error whenever trying to create an instance of the client (
getAlertsClient
viagetAlertsClientWithRequest
) and the encrypted saved objects plugin is using an ephemeral encryption key.Error message: