[Fleet][Endpoint][RBAC V2] Update fleet router and config to allow API access via RBAC controls

[ashokaditya]

Summary

Note

This PR is adding changes only to some of api/fleet/package_policies
API routes, there will be subsequent PRs after this to update
api/fleet/epm/packages, api/fleet/agent_policeis and,
api/fleet/agent_status.

This PR introduces the framework needed in fleet in order to be able to
support Package level Privileges - meaning: if a user does not have
authorization granted via Fleet and/or Integration privileges, then
package level privileges are check and API access granted. When access
is granted based on Package Privileges, the data is also validated to
ensure that it is limited to the integration package names that were
given authorization to the API.

The following APIs were updated to leverage this new framework:

• Integration Package Policy list API
• Integration Package Policy get one API
• Integration Package Policy update one API
• Integration Package Policy bulk get API

ℹ️ these API were updated in support of Endpoint use cases needed for
v8.7.

Example of API error for Package policies api:

{
    "statusCode": 403,
    "error": "Forbidden",
    "message": "Authorization denied to [package.name=fleet_server]. Allowed package.name's: endpoint"
}

---

To test:

1. Log in as elastic/superuser and create some agent policies.

2. Under Stack Management, create a role policy_role with the
   following RBAC settings. DO NOT select Fleet -> All or toggle
   Integrations. Leave those RBAC toggles set to None
   

3. Create a user e.g. policy_user and assign them only the above
   role. NOT superuser.

4. Login with this user and navigate to
   app/security/administration/policy or curl/postman.

5. Expect to see the following:

• GET api/fleet/epm/packages?category=security should return a 403
  status.
• GET
  api/fleet/package_policies?page=1&perPage=10&kuery=ingest-package-policies.package.name%3A%20endpoint
  should return a list of policies.
• GET /api/fleet/package_policies/<packagePolicyId> should return a
  200 and a signle item that has the policie's details. Note that the
  package name of this item is endpoint.
• there should be a POST API request matching
  api/fleet/agent_policies/_bulk_get, and should return a 403.

5. With Policy Management RBAC set to All

• PUT
  http://localhost:5601/api/fleet/package_policies/<packagePolicyId>
  should return a 200 with the updated policy details as response

Checklist

• Unit or functional
  tests
  were updated or added to match the most common scenarios

• This was checked for breaking API changes and was labeled
  appropriately

Co-authored-by: Paul Tavares paul.tavares@elastic.co

[paul-tavares]

@juliaElastic ,

Re:

Is the agent policy API going to filter out the package policies that do not belong to endpoint package?

I'm not sure yet about how this one should be implemented and it warrants some discussions. Our Endpoint use cases don't need update/create/delete access, so for us, it would be ok to filter out any package policy that does not match the authz package names. But for cases (in the future or for other integrations) where Update/Delete is needed, that gets more complicated.

@ashokaditya,
we need to explore each one of these individually and see if we can come up with good suggestions on the approach. We should use the tracking issues you created to expand upon this.

[paul-tavares]

@ashokaditya ,
I took a look through and am good with the changes. I'm not going to approve it just because I worked with you on this. I'll defer approval to the Fleet team

[juliaElastic]

The code looks good to me, I'll do a few manual tests locally before I approve.

[juliaElastic]

I noticed something strange, I created a role that has access to Fleet:All and Integrations:Read, and I'm getting a permission denied error on Fleet/Agents screen.
The same role has access on the dev-oblt cluster, so might be a regression from this pr.

Though it might be a difference between environments, as the dev-oblt doesn't use the fleetServerSetup=true param in the check-permissions request

EDIT: seeing the same behavior on main branch, so it is not caused by this pr.

[juliaElastic]

LGTM, tested locally with the endpoint role and existing fleet/integrations role

[nchaulet]

LGTM 🚀

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 26b2b46

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
fleet	923	922	-1

Page load bundle

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

id	before	after	diff
fleet	120.8KB	120.8KB	+1.0B

Unknown metric groups

API count

id	before	after	diff
fleet	1028	1027	-1

ESLint disabled in files

id	before	after	diff
osquery	1	2	+1

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
fleet	61	67	+6
osquery	109	115	+6
securitySolution	445	451	+6
total			+20

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
fleet	70	76	+6
osquery	110	117	+7
securitySolution	521	527	+6
total			+21

History

• 💚 Build #94637 succeeded 442d72a
• 💛 Build #94595 was flaky 3a5c7c0
• 💚 Build #94506 succeeded 2f9c229
• 💔 Build #94396 failed 1650a0c
• 💔 Build #94391 failed 68e366a
• 💚 Build #94305 succeeded a186363

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

cc @ashokaditya