Skip to content
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

Conversation

mikecote
Copy link
Contributor

@mikecote mikecote commented Feb 3, 2020

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 via getAlertsClientWithRequest) and the encrypted saved objects plugin is using an ephemeral encryption key.

Error message:

Unable to create alerts client due to the Encrypted Saved Objects plugin using an ephemeral encryption key. Please set xpack.encryptedSavedObjects.encryptionKey in kibana.yml

@mikecote mikecote added review Feature:Alerting v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.7.0 Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Feb 3, 2020
@mikecote mikecote self-assigned this Feb 3, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

Copy link
Contributor

@peterschretlen peterschretlen left a 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?

@mikecote
Copy link
Contributor Author

mikecote commented Feb 4, 2020

@peterschretlen

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!,
Copy link
Contributor Author

@mikecote mikecote Feb 4, 2020

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.

Copy link
Member

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

@peterschretlen peterschretlen Feb 4, 2020

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

Copy link
Member

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 ...

@mikecote mikecote force-pushed the alerting/disable-alert-APIs-when-eso-gen-key branch from bce4018 to b34fa68 Compare February 4, 2020 18:11
@mikecote mikecote changed the title Disable alerting APIs when ESO plugin is using an ephemeral encryption key Disable creating alert client instances when ESO plugin is using an ephemeral encryption key Feb 4, 2020
@mikecote
Copy link
Contributor Author

mikecote commented Feb 4, 2020

@gmmorris @peterschretlen @pmuellr let me know your thoughts. I've made the changes based on the discussion we've had here: #56676 (comment).

Copy link
Member

@pmuellr pmuellr left a 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

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.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Copy link
Contributor

@peterschretlen peterschretlen left a 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.

@mikecote
Copy link
Contributor Author

mikecote commented Feb 4, 2020

@pmuellr thanks for the review! I will create a follow up issue for your comments: #56676 (review).

@mikecote mikecote merged commit e74ab19 into elastic:master Feb 4, 2020
mikecote added a commit to mikecote/kibana that referenced this pull request Feb 4, 2020
mikecote added a commit that referenced this pull request Feb 5, 2020
…ng an ephemeral encryption key (#56676) (#56791)

* Fix merge conflicts

* Fix

* Fix test failures
@mikecote mikecote added the v7.6.0 label Feb 5, 2020
gmmorris added a commit to gmmorris/kibana that referenced this pull request Feb 5, 2020
* 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)
  ...
mikecote added a commit that referenced this pull request Feb 5, 2020
…ephemeral encryption key (#56676) (#56790)

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
majagrubic pushed a commit to majagrubic/kibana that referenced this pull request Feb 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Alerting release_note:fix review Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v7.6.0 v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants