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

Fix enable and disable API to still work when AAD is out of sync #56634

Merged

Conversation

mikecote
Copy link
Contributor

@mikecote mikecote commented Feb 3, 2020

Solves the enable and disable API for #56619.

In this PR, I'm allowing alerts to be enabled and disabled even when the AAD is out of sync. I'm also refactoring the enable and disable unit tests of the alerts client.

The code to invalidate API keys was previously at the wrong place (enable API) when it should of been at the disable API.

@mikecote mikecote added Feature:Alerting v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.7.0 v7.6.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
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 so far

expect(e.status).to.eql(404);
}
// Ensure AAD isn't broken
await checkAAD({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess AAD is now "fixed" (it was "broken" just above), because the enable() call "fixed" it. Interesting. That seems fine for alerts, I wonder if it would end up being a security issue with actions, when we get to fixing it's related encryption key issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this scenario we're lucky. For actions, I believe all the secrets have to be passed in for any sort of update to the SO. We probably won't have this issue of loading the decrypted object beforehand in the actions client, I think.

@mikecote mikecote marked this pull request as ready for review February 6, 2020 20:18
@mikecote mikecote requested a review from a team as a code owner February 6, 2020 20:18
@mikecote mikecote added the review label Feb 6, 2020
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

History

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

@elastic elastic deleted a comment from kibanamachine Feb 6, 2020
@peterschretlen peterschretlen self-requested a review February 7, 2020 15:13
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 think we still need to call invalidateApiKey() when enabling

@@ -395,12 +390,32 @@ export class AlertsClient {
);
const scheduledTask = await this.scheduleAlert(id, attributes.alertTypeId);
await this.savedObjectsClient.update('alert', id, { scheduledTaskId: scheduledTask.id });
await this.invalidateApiKey({ apiKey: attributes.apiKey });
Copy link
Contributor

@peterschretlen peterschretlen Feb 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some cases we still need the invalidate. As-is, the code assumes that prior to calling enable() no API key exists.
I tested this with detection rules, and this results in dangling API keys because sometimes an alert is updated before calling enable():

  1. Create a custom rule, with the rule disabled. This will call create() and generate an API key k1
  2. Enable the rule
    1. calls update(), this creates a new API key k2 and invalidates the old one k1
    2. calls enable(), which in this case creates a new key k3. k2 doesn't get invalidated.

Even after fixing #57036, if update() is called before enable() you will end up with a dangling key.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review 🙏 I see what you mean, I've also noticed this strange behaviour when fixing #57036 and created #57099 from that. This would solve the problem, but it never hurts to add a check here as well so I will do the change 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in f1367ec.

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 - thanks!

@mikecote
Copy link
Contributor Author

mikecote commented Feb 7, 2020

@elasticmachine merge upstream

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

@mikecote
Copy link
Contributor Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

@mikecote mikecote merged commit 8155415 into elastic:master Feb 10, 2020
mikecote added a commit to mikecote/kibana that referenced this pull request Feb 10, 2020
…stic#56634)

* Fix enable and disable API to still work when AAD is broken

* Load SO once before fallback

* Fix comment

* Invalidate API key if any in enable API

* Add missing integration test

Co-authored-by: Elastic Machine <[email protected]>
gmmorris added a commit to gmmorris/kibana that referenced this pull request Feb 11, 2020
* master: (34 commits)
  [Index management] Server-side NP ready (elastic#56829)
  Webhook action - make user and password secrets optional (elastic#56823)
  [DOCS] Removes reference to IRC (elastic#57245)
  [Monitoring] NP migration: Local angular module (elastic#51823)
  [SIEM] Adds ECS link to help menu (elastic#57104)
  Ensure http interceptors are shares across lifecycle methods (elastic#57150)
  [Remote clusters] Migrate server code out of legacy (elastic#56781)
  fixes render bug in alert list (elastic#57152)
  siem 7.6 updates (elastic#57169)
  Make the update alert API key API work when AAD is out of sync (elastic#56640)
  fix(NA): MaxListenersExceededWarning on getLoggerStream (elastic#57133)
  [Metrics UI] Setup commonly used time ranges in timepicker (elastic#56701)
  [Maps] set filter.meta.key to geoFieldName so query passes filterMatchesIndex when ignoreFilterIfFieldNotInIndex is true (elastic#56692)
  Create plugin mock for event log plugin (elastic#57048)
  fix ts error on master (elastic#57236)
  Don't create API key for disabled alerts when calling create API (elastic#57041)
  Fix enable and disable API to still work when AAD is out of sync (elastic#56634)
  [DOCS] Canvas embed objects (elastic#57156)
  Delete autocomplete namespace (elastic#57187)
  Security - Inject logout url (elastic#57201)
  ...
mikecote added a commit that referenced this pull request Feb 11, 2020
) (#57238)

* Fix enable and disable API to still work when AAD is broken

* Load SO once before fallback

* Fix comment

* Invalidate API key if any in enable API

* Add missing integration test

Co-authored-by: Elastic Machine <[email protected]>

Co-authored-by: Elastic Machine <[email protected]>
@mikecote mikecote added release_note:fix and removed release_note:skip Skip the PR/issue when compiling release notes labels Apr 15, 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.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants