[Serverless][Security Solution][Endpoint] Remove use of hooks to check access to.lists-* for endpoint exceptions access

[ashokaditya]

Summary

Instead of using useListsConfig this PR uses useListPrivileges to verify access to .lists-* index pattern.

follow up of /pull/165613
related /pull/170671 (closed in favour of this)
fixes /issues/169268

Checklist

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

[e40pud]

LGTM!

[rylnd]

This looks like it was a partial copy/paste from useListsConfig, e.g. needsConfiguration had a more comprehensive definition originally, and as such isn't quite correct here. But that logic was also specific to creating the lists index, and I think you could eliminate it entirely here (it doesn't matter whether they could create the index, we're not trying to do that here):

Suggested change

	const enabled = lists != null;
	const needsIndexConfiguration = canManageIndex === false;
	const needsConfiguration = !enabled || needsIndexConfiguration;
	const hasAccessToLists = !(privilegesLoading || needsConfiguration);
	const listsEnabled = lists != null;
	const hasListsAccess = canManageIndex;
	const canUseLists = !privilegesLoading && listsEnabled && hasListsAccess

However, I had a question about the definition of hasListsAccess, since the above shows more clearly that this is centered around the canManageIndex privilege: If this capability requires reading/writing lists data, then canReadIndex and canWriteIndex from useListsPrivileges are what you want, here: manage has no relation to that concept.

[ashokaditya]

Thanks for looking into this @rylnd. I do think using canReadIndex and canWriteIndex makes more sense than the manage privilege. I'll make that change.

[ashokaditya]

9a079cf

[ashokaditya]

and 2c02033

[ashokaditya]

@rylnd @kqualters-elastic @yctercero I'm now wondering if there's a way to verify index privileges on the server side for API requests. I'm testing with a role that has read access to .lists-* index and also has endpoint_exceptions_all kibana privilege, such as

{
    "metadata": {},
    "elasticsearch": {
        "cluster": [],
        "indices": [
            {
                "names": [
                    ".items-*",
                    ".alerts-security.alerts-*"
                ],
                "privileges": [
                    "view_index_metadata",
                    "read",
                    "write",
                    "manage"
                ],
                "field_security": {
                    "grant": [
                        "*"
                    ],
                    "except": []
                },
                "allow_restricted_indices": false
            },
            {
                "names": [
                    ".lists-*"
                ],
                "privileges": [
                    "read",
                    "manage",
                    "view_index_metadata"
                ],
                "field_security": {
                    "grant": [
                        "*"
                    ],
                    "except": []
                },
                "allow_restricted_indices": false
            }
        ],
        "run_as": []
    },
    "kibana": [
        {
            "base": [],
            "feature": {
                "siem": [
                    "minimal_all",
                    "endpoint_list_all",
                    "endpoint_exceptions_all"                
                 ]
            },
            "spaces": [
                "*"
            ]
        }
    ]
}

which does restrict the role from doing any CUD operations on the UX as expected.

However, on the API side the role is able to do CUD operations, since endpoints exceptions are added to saved objects and now I'm wondering if we need index access for it at all? Or is there a way to restrict saved objects access using index privileges?

[rylnd]

@ashokaditya I think there's a lot of context here that I'm missing. Is there a ticket describing the behavior that you're trying to achieve here? Is this a bugfix that's triggered a permissions discussion?

Broadly, though: we typically are not proactive with ES permissions checking on the server, and instead attempt to perform the requested action as the user requesting it. If an error is raised within ES, we will surface that as part of the response.

[ashokaditya]

Thanks again for looking into this @rylnd . Apologies for not providing context. The idea is to restrict endpoint exceptions for serverless users. Sepecifically when a user doesn't have any endpoint PLI (essentials/complete) they should not be able to access endpoint exceptions. Here is the first PR that introduced this check.

After talking to my team, looks like we don't need the index privilege check at all, much like we don't for other endpoint artefacts (trusted apps, event filters etc.). We drive this purely via kibana privileges. So in the end, we don't need to use the useListsPrivileges for checking permissions to .lists-* indices.

[ashokaditya]

@paul-tavares @dasansol92 @semd ☝🏼

[ashokaditya]

@kqualters-elastic @yctercero looks like we might need to look into this a bit more. "Endpoint exceptions" is not similar to endpoint artefacts and so I'm not so sure if access to it should be similar to endpoint artefacts. I'm going to try and find a time so we can quickly discuss this offline.

[ashokaditya]

I spoke with @vitaliidm offline and looks like endpoint exceptions do not need .lists-* permissions.

[ashokaditya]

@elasticmachine merge upstream

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: c025f9e

Failed CI Steps

• FTR Configs #1
• FTR Configs #47
• FTR Configs #56
• FTR Configs #64

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
@kbn/core-test-helpers-test-utils	9	-	-9
@kbn/securitysolution-ecs	337	-	-337
expressionHeatmap	108	-	-108
total			-454

Any counts in public APIs

Total count of every any typed public API. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats any for more detailed information.

id	before	after	diff
@kbn/securitysolution-ecs	1	-	-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	12.8MB	12.8MB	+6.0KB
securitySolutionServerless	330.6KB	336.9KB	+6.3KB
total			+12.3KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
@kbn/securitysolution-ecs	32	-	-32
expressionHeatmap	2	-	-2
total			-34

Page load bundle

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

id	before	after	diff
securitySolutionServerless	41.7KB	41.7KB	-1.0B

Unknown metric groups

API count

id	before	after	diff
@kbn/core-test-helpers-test-utils	9	-	-9
@kbn/securitysolution-ecs	341	-	-341
expressionHeatmap	112	-	-112
total			-462

ESLint disabled line counts

id	before	after	diff
@kbn/securitysolution-ecs	1	-	-1
expressionHeatmap	1	-	-1
total			-2

References to deprecated APIs

id	before	after	diff
expressionHeatmap	3	-	-3

Total ESLint disabled count

id	before	after	diff
@kbn/securitysolution-ecs	1	-	-1
expressionHeatmap	1	-	-1
total			-2

History

• 💔 Build #178054 failed 82e3236
• 💔 Build #177855 failed da91adb
• 💔 Build #177826 failed 21abb7a
• 💔 Build #177563 failed 652a39d
• 💔 Build #177562 failed 652a39d

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

cc @ashokaditya

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.11

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

Questions ?

Please refer to the Backport tool documentation