Moved scheduleNow call to privmon engine init instead of monitoring source engine - bug fix

[CAWilson94]

Summary

This PR moves the scheduleNow call from the monitoring engine initialization to the privilege monitoring initialisation step. This change ensures the task is only scheduled after the Privileged Monitoring Engine has been properly created and is ready — resolving the dependency issue.

The flow for starting a sync with the monitoring engine is -

1. Create privileged users.
2. Register these with the monitoring source
3. Initialise the privilege monitoring engine - will trigger scheduleNow, and therefore the task.

Also added a try catch around engine status for handling the case of status undefined within scheduleNow call.

Testing Changes

1. Open fresh kibana and ES
2. Enable Advanced Settings

UI Test:

1. Navigate to privileged monitoring page
2. Select index modal - create new index from here
3. Select 'add Privileged users'

Look at kibana logs - "Running privilege monitoring task" should show
UI should have closed modal, onto the privmon screen.

Dev Tools Test:

1. Create test index/ indicies

PUT /tatooine-
{
  "mappings": {
    "properties": {
      "user": {
        "properties": {
          "name": {
            "type": "keyword",
            "fields": {
              "text": {
                "type": "text"
              }
            }
          }
        }
      }
    }
  }
}

2. OPTIONAL - Add some users to this

POST tatooine-/_bulk
{ "index": {} }
{ "user": { "name": "Luke Skywalker" } }
{ "index": {} }
{ "user": { "name": "Leia Organa" } }
{ "index": {} }
{ "user": { "name": "Han Solo" } }
{ "index": {} }
{ "user": { "name": "Chewbacca" } }
{ "index": {} }
{ "user": { "name": "Obi-Wan Kenobi" } }
{ "index": {} }
{ "user": { "name": "Yoda" } }
{ "index": {} }
{ "user": { "name": "R2-D2" } }
{ "index": {} }
{ "user": { "name": "C-3PO" } }
{ "index": {} }
{ "user": { "name": "Darth Vader" } }

3. Register Monitoring Entity Source Saved Objects

POST kbn:/api/entity_analytics/monitoring/entity_source
{
  "type": "index",
  "name": "StarWars",
  "managed": true,
  "indexPattern": "tatooine-",
  "enabled": true,
 "matchers": [
    {
      "fields": ["user.role"],
      "values": ["admin"]
    }
  ],
  "filter": {}
}
 

4. Initialise monitoring engine:

POST kbn:/api/entity_analytics/monitoring/engine/init {}

Should all work as expected (famous last words)

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/security-entity-analytics (Team:Entity Analytics)

[machadoum]

I believe that after this change, the schedule won't run after an update, which is the desired scenario.

[CAWilson94]

Gotcha, I thought it would still be running the same task that was triggered by privmon data client init, so would pick up from there. But will put this back in if its not the case - I think update should be safe and have resources then.

[machadoum]

Hey @CAWilson94!

You have identified the problem with precision. We try to schedule the engine before it is installed. But the current solution causes another problem. I think we need to solve the bug in the source.

From what I understand, it comes from:

    const currentEngineStatus = await this.getEngineStatus();

My suggestion is to update getEngineStatus so it doesn't throw an error when the engine is not installed. Instead, it should return that it is not installed.

That would require adding a new status, and we must be aware that this will impact other places that call getEngineStatus, which will also be affected, like healthCheckPrivilegeMonitoringRoute.

A quicker solution is to swallow the exception on schedule.now implementation and only log it.

[machadoum]

This was wrong

[machadoum]

I added a new status return by getEngineStatus, instead of throwing an error.

[machadoum]

If the schedule fails, we warn in the console but keep going...

[machadoum]

Only schedule if the engine is enabled.

This line is the main bug fix; all other changes are extra safety checks to prevent the same bug from happening when calling scheduleNow from other areas.

[tiansivive]

shouldnt the scheduleNow do all those checks instead?

[machadoum]

This isn't strictly required for the bug fix, but it is a good way to prevent similar bugs in the future.

[tiansivive]

I think this fixes the bug but we should double check if we can do all the required cehcks inside the ScheduleNow function

[hop-dev]

Tested locally 👍

[natasha-moore-elastic]

Approved for Docs

[kibanamachine]

Starting backport for target branches: 9.1

https://github.com/elastic/kibana/actions/runs/16728199440

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: e250306

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	7814	7815	+1

Async chunks

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

id	before	after	diff
securitySolution	10.3MB	10.3MB	+411.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	94.4KB	94.4KB	-1.0B

History

• 💔 Build #325958 failed 3ba7959
• 💔 Build #325856 failed fccfbda
• 💔 Build #325719 failed 5118b08
• 💔 Build #325649 failed 43d5c4e

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	9.1

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation