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 alerting or alerting APIs when no encryptionKey is set for the encrypted saved objects plugin #56420

Closed
mikecote opened this issue Jan 30, 2020 · 8 comments
Assignees
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v7.7.0

Comments

@mikecote
Copy link
Contributor

mikecote commented Jan 30, 2020

We may have to change this solution later on to support new platform. We should also expose this so other plugins know they can't use alerting (ex: SIEM).

PRs:

Related issue: #56448.

@mikecote mikecote added Feature:Alerting v7.6.0 Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Jan 30, 2020
@elasticmachine
Copy link
Contributor

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

@pmuellr
Copy link
Member

pmuellr commented Jan 30, 2020

I'd think the long-term solution would be to have cloud generate an encryption key, so everyone gets one by default. Whether they can change it (for invalidation purposes) is another question :-)

Short term, I guess this is kind of a soft-disable on alerting APIs - we can't actually have the plugin itself disabled, it seems like.

This is for actions as well, I'd guess? But probably not a 7.6 issue as no one is using actions at all in 7.6. If we need to do this for 7.7 as well though, I'd guess we will need the same for actions.

And task manager? Aye-yi-yi ...

But maybe there's a blessing there - we can have task manager figure out whether the encryptionKey is set, and then alerting and actions can check that at plugin setup|start time, just so we don't have to calculate it in all the plugins.

@pmuellr
Copy link
Member

pmuellr commented Jan 30, 2020

I think SIEM is affected, in that for cloud they will be the only visible place a customer would realize the encryption key isn't set. Because, no Kibana logs :-(. Ie, they're going to have to realize alerting is soft-disabled because of this, and provide a message in the UI directing the user to resolve it.

@mikecote
Copy link
Contributor Author

@pmuellr

I'd think the long-term solution would be to have cloud generate an encryption key, so everyone gets one by default.

Totally agree and the idea is in the works on Cloud's side.

This is for actions as well, I'd guess?

Correct, just the execute function that encrypts the API key and uses Task Manager would get disabled.

And task manager?

Task manager should be ok, it doesn't use encrypted saved objects directly.

I think SIEM is affected, in that for cloud they will be the only visible place a customer would realize the encryption key isn't set. Because, no Kibana logs :-(. Ie, they're going to have to realize alerting is soft-disabled because of this, and provide a message in the UI directing the user to resolve it.

SIEM is planning to add UX based on a value we expose. They would indicate to the user an encryptionKey isn't set and needs to be in order to use the detection engine.

@mikecote mikecote self-assigned this Jan 30, 2020
@mikecote
Copy link
Contributor Author

Created a discuss issue #56448. The outcome of it will define what to do for 7.6 in this issue.

@pmuellr
Copy link
Member

pmuellr commented Jan 30, 2020

This is for actions as well, I'd guess?

Correct, just the execute function that encrypts the API key and uses Task Manager would get disabled.

I think the create and update action APIs as well, since they write the secrets via ESO. execute also needs it to read those secrets.

@mikecote
Copy link
Contributor Author

I think the create and update action APIs as well, since they write the secrets via ESO. execute also needs it to read those secrets.

Ah, you're right! Totally forgot about the origin of ESOs 😄

@mikecote
Copy link
Contributor Author

Closing as all sub-PRs are merged.

@mikecote mikecote added v7.7.0 and removed v7.6.0 labels Feb 12, 2020
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v7.7.0
Projects
None yet
Development

No branches or pull requests

4 participants