[Meta] Use kibana_system to write to .fleet-* indices

[joshdover]

We are considering not allowing superuser to write Fleet's .fleet-* system indices in a future 8.x release. Only the kibana_system (internal user) will be able to write to these indices. This requires that we update all places where we are writing to these indices to use kibana_system and add any necessary, explicit authz checks. These authz checks should be checking against the context.fleet.authz.fleet.all property added in #119199.

• .fleet-enrollment-api-keys
  • Internal usages [Fleet] Use internal ES client to access .fleet system indices #119992
• .fleet-agents
  • Internal usages [Fleet] Use internal ES client to access .fleet system indices #119992
  • Usages in other plugins [Fleet] Add scoped AgentService #119017
• .fleet-policies and .fleet-policies-leader
  • Internal usages [Fleet] Use internal ES client to access .fleet system indices #119992
• .fleet-servers
  • Internal usages (there are no writes from Kibana itself)
  • Usages in Security Solution's resolver_generator_script:

    kibana/x-pack/plugins/security_solution/common/endpoint/data_loaders/index_fleet_server.ts

    Line 33 in f1aae77

    index: FLEET_SERVER_SERVERS_INDEX,

• .fleet-actions and .fleet-actions-results
  • Internal usages
  • Usages in Security Solution's resolver_generator_script:

    • kibana/x-pack/plugins/security_solution/common/endpoint/data_loaders/index_fleet_actions.ts

      Line 140 in f1aae77

      index: AGENT_ACTIONS_INDEX,

    • kibana/x-pack/plugins/security_solution/common/endpoint/data_loaders/index_fleet_actions.ts

      Line 80 in f1aae77

      index: AGENT_ACTIONS_RESULTS_INDEX,

  • Usages in Security Solution's host isolation endpoint:

    kibana/x-pack/plugins/security_solution/server/endpoint/routes/actions/isolation.ts

    Line 219 in f1aae77

    fleetActionIndexResult = await esClient.index<EndpointAction>({

• .fleet-artifacts
  • Already covered here:

    kibana/x-pack/plugins/fleet/server/plugin.ts

    Line 383 in f1aae77

    return new FleetArtifactsClient(core.elasticsearch.client.asInternalUser, packageName);

@kevinlog I believe the only product-facing impact remaining is the .fleet-actions write being done in the isolation endpoint. It seems this resolver_generator_script is a dev tool that we could fix out of band. Would you agree?

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[elasticmachine]

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

[joshdover]

@ashokaditya I'd like to open a PR for 8.0 that switches this ES call over to always use the internal user:

kibana/x-pack/plugins/security_solution/server/endpoint/routes/actions/isolation.ts

Lines 219 to 228 in f1aae77

	fleetActionIndexResult = await esClient.index<EndpointAction>({
	index: AGENT_ACTIONS_INDEX,
	body: {
	...doc.EndpointActions,
	'@timestamp': doc['@timestamp'],
	agents,
	timeout: 300, // 5 minutes
	user_id: doc.user.id,
	},
	});

This will help prevent issues where the "Isolate host" button would when Elasticsearch is upgraded to 8.1 (the version where superuser will not have write access to this index) but Kibana hasn't yet been upgraded. Since we'll be switching over to use the internal user, we need to ensure the end-user making the request to Kibana should have the ability to create these actions. What authz check should be added to verify this user should have access to this action or can I rely on the existing checks?

[kevinlog]

What authz check should be added to verify this user should have access to this action or can I rely on the existing checks?

@joshdover I believe you can rely on the existing checks. If the user is a superuser or has all permissions on fleet, then they should be able to create a Fleet action/Isolate hosts, etc.

@paul-tavares @ashokaditya - let me know if that makes sense

[paul-tavares]

Yes, this makes sense to me. A user should have full access to fleet in order to create actions - at least from our Endpoint perspective. @joshdover you should also get some feedback from the OSQuery team - I'm pretty sure they also use this index.

cc/ @pzl since he did the initial implementation of isolation support

[joshdover]

Thanks, @paul-tavares. I took a look at the OSQuery code and they're using internal user for all writes so I don't think there's any issue there.