[Security Solutions][Detection Engine] Adds a warning banner when the alerts data has not been migrated yet.

[FrankHassanabad]

Summary

Adds a warning banner for when the alerting/signals data has not been migrated to the new structure. Although we are planning on supporting some backwards compatibility where the rules don't completely blow up, this support of backwards compatibility is going to be best effort and not have explicit tests and checks against backwards compatibility. Hence the reason we need to alert any users of the system when we can that they should have an administrator visit the detections page to start a migration.

From previous reasons why we don't migrate on startup of Kibana is that there are multiple instances running and it might be a worse situation so we migrate on page visit by an administrator to reduce chances of issues. In the future we might revisit this decision but for now this is what we have moved forward with.

If the user does not have sufficient privileges such as t1 analyst to see if they have should upgrade, no message is shown to those users.

This PR adds the following banner which is non-dismissible to:

• Main detections page
• Manage rules page
• View/Edit rules page

If other dismissible alerts are on the page then you will get a stacked effect until you dismiss those messages. Again, this message cannot be dismissed intentionally to let the user know that they should contact an administrator to update/upgrade the alerting/signal data:

Other items of note:

• Added ability to remove the button from the callouts
• Consolidated in one area some types
• Removed one part of the callout that has branching logic we never activate. We can re-add that later if we do have a need for it
• e2e Cypress tests added to detect when the banner should be present
• Backfilled unit tests for enzyme for some of the callout code

Manual testing:
Bump this number in your dev env:
https://github.com/elastic/kibana/blob/master/x-pack/plugins/security_solution/server/lib/detection_engine/routes/index/get_signals_template.ts#L11

Give yourself these permissions (or use one of the scripts for creating these roles):

Visit the page.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

[banderror]

Thank you! I'm super sorry, didn't have enough time to carefully review this PR today. Posted some comments, would look at it closer tomorrow morning if it's still open. Pls don't wait for me if other people approve it.

[banderror]

Did I noticed it right that there's a bunch of very similar spec.ts files which test the same behaviour, with the only difference in the role of the user? Here it's ROLES.t1_analyst, in the other files all the other roles we have?

I'm thinking maybe it's possible to run describe() blocks in a for loop and pass these roles and other required parameters as "test cases"? Just like we can do

cases.forEach(c => {
  it(c.name, ...
});

maybe we could use the same trick with describe blocks.

[FrankHassanabad]

These behave differently for each role in most cases. For example in some roles we have to test for some callouts and in others we have to test for the non-existent.

E.x.

    it('We show three primary callouts', () => {
      waitForCallOutToBeShown(ALERTS_CALLOUT, 'primary');
      waitForCallOutToBeShown(RULES_CALLOUT, 'primary');
      waitForCallOutToBeShown(NEED_ADMIN_FOR_UPDATE_CALLOUT, 'primary');
    });

vs. in another test:

    it('We show 1 primary callout', () => {
      getCallOut(ALERTS_CALLOUT).should('not.exist');
      getCallOut(RULES_CALLOUT).should('not.exist');
      getCallOut(NEED_ADMIN_FOR_UPDATE_CALLOUT).should('not.exist');
    });

So each look similar but in the details of each they are very different from each other.

[banderror]

Hmm, do you think this test should check NEED_ADMIN_FOR_UPDATE_CALLOUT as well? I'd check this one only in the newly added tests.

[FrankHassanabad]

Yeah, because with this role I do not want the NEED_ADMIN_FOR_UPDATE_CALLOUT to end up showing per the user's role and the fact that this test will return index_mapping_outdated: false.

The other test that is the companion to this one is:

alerts_detection_callouts_readonly_need_admin.spec.ts

Where it returns index_mapping_outdated: true and then I test to ensure that it shows up next to each of these callouts.

[banderror]

Maybe we could omit checking these guys in all tests which check the behaviour of NEED_ADMIN_FOR_UPDATE_CALLOUT?

[FrankHassanabad]

I think these are missing tests for the callouts since so far what we have been testing is that callouts will appear when they're supposed to appear based on a lack of permissions. However, the other flip side is that we need tests based on when the user has sufficient permissions and some if not all the callouts should not appear.

So, without tests that are checking for the non-existence of callouts when users have sufficient privileges we could introduce bugs where callouts show up on pages when users have sufficient privileges and we wouldn't catch it. With these additional tests in place we should hopefully catch all if not most of the test cases where:

• Users have such sufficient privileges that no callouts appear.
• Users do not have sufficient privileges and 1 or more of the callouts should appear.
• Repeat the same two tests but now with index_mapping being outdated.

[banderror]

So, without tests that are checking for the non-existence of callouts when users have sufficient privileges we could introduce bugs where callouts show up on pages when users have sufficient privileges and we wouldn't catch it

That's a great point, I agree! However after re-reading all my comments, and the answers, and checking the code I think I just failed to explain what I meant. Would you have some time to chat on that stuff specifically?

[banderror]

So, without tests that are checking for the non-existence of callouts when users have sufficient privileges we could introduce bugs where callouts show up on pages when users have sufficient privileges and we wouldn't catch it

That's a great point, I agree! However after re-reading all my comments, and the answers, and checking the code I think I just failed to explain what I meant. Would you have some time to chat on that stuff specifically?

[banderror]

Thank you for adding unit tests. 🚀

[banderror]

Let's maybe import from ./callout_types to avoid circular deps?

[FrankHassanabad]

Yeah I can do that.

[banderror]

Ooops again 🙂

[FrankHassanabad]

I can change this one to be ./index but usually for index.ts based files I just import from the folder directly vs something like ./index and not find that a big issue with circles.

[banderror]

Oh, I see, here it's not a big deal. Np 👍

[banderror]

Thank you for additional comments, again super useful thing.
Nit: not sure what do you mean here by "Have the permissions to be able to read" and "If the user has the permissions to see"?

[FrankHassanabad]

Adding these comments. Let me know if it clears things up:

 * Some users do not have sufficient privileges to be able to determine if "signalIndexMappingOutdated"
 * is outdated or not. Same could apply to "hasIndexManage". When users do not have enough permissions
 * to determine if "signalIndexMappingOutdated" is true or false, the permissions system returns a "null"
 * instead.

[banderror]

Super clear, thank you

[banderror]

Here signalIndexMappingOutdated != null and hasIndexManage != null means that they have been loaded and now are available for checking.

Considering that, I suspect that condition might be incorrect.

signalIndexMappingIsOutdated && !userHasIndexManage ===
signalIndexMappingIsOutdated && !(hasIndexManage != null && hasIndexManage) ===
signalIndexMappingIsOutdated && hasIndexManage == null && !hasIndexManage) where
hasIndexManage == null && !hasIndexManage gives true when we are in initial state,
which would lead to flickering.

I think this is the right one:

const signalIndexMappingIsOutdated =
    signalIndexMappingOutdated != null && signalIndexMappingOutdated;
const userDoesntHaveIndexManage = hasIndexManage != null && !hasIndexManage;

condition={signalIndexMappingIsOutdated && userDoesntHaveIndexManage}

[FrankHassanabad]

Great catch here. I agree. Just want to point out one additional use case which is:

The null can be set when it's in an initial condition as well as when the user does not have enough privileges to even determine if signalIndexMappingOutdated is set to true or false so null is a overloaded in that it can stay null when the user does not know if they have enough privileges to determine if the signals index mapping is outdated as well as initial page load when it hasn't fetched anything yet. We might at some point want the user to know for sure rather than work around the limitation which might be trickier as we would end up using a system based user to determine if the user has the limitation or not.

But for now, that is the limitation and a side effect is that users without enough privileges won't show that they should contact an admin.

For hasIndexManage that could be the case maybe too where the user doesn't have enough privileges to determine if they do or do not have the ability to manage an index. I think this is more doubtful looking at the code on the backend but it might change later depending on how we create the permission from other permissions.

Regardless, I think what you're saying here is better and valid of avoiding having a flicker and still satisfies the use cases/limitations outlined above at the moment. I will add this line as suggested:

const userDoesntHaveIndexManage = hasIndexManage != null && !hasIndexManage;

Thanks for the hard look at this 👍

[banderror]

LGTM, thank you!

[banderror]

One more thought I had. In this callout we say "auto-migrate", signals migration etc. Do you think it should be clear enough for the user what do we mean by that? Might sound scary IMHO :)

Do we have docs on signals migration? Maybe we could link to them and/or explain what this migration is about, how it works and why it's needed.
Could go in a separate PR.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: efec9c3

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	2190	2192	+2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	7.5MB	7.6MB	+3.5KB

History

• 💚 Build #105388 succeeded dc62dc7
• 💚 Build #105008 succeeded e2be038
• 💚 Build #104991 succeeded eb78eb6
• 💛 Build #104419 was flaky 68b8cd1
• 💚 Build #104417 succeeded 0340413

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

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)