[Endpoint] EMT-issue-65: add endpoint list api #53861

nnamdifrankie · 2019-12-31T02:25:38Z

Summary

Summarize your PR. If it involves visual changes include a screenshot or gif.

This PR enables the api to retrieve the list of endpoints from the elastic search backend. It collapses the all the records received for all endpoints to to their latest record. It maps the data to a simplified data structure. This PR only handles the list return, the details api will be handled in another PR.

Checklist

Use ~~strikethroughs~~ to remove checklist items you don't feel are applicable to this PR.

~~- [ ] This was checked for cross-browser compatibility, including a check against IE11~~
~~- [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support~~
~~- [ ] Documentation was added for features that require explanation or tutorials~~

Unit or functional tests were updated or added to match the most common scenarios
~~- [ ] This was checked for keyboard-only and screenreader accessibility~~

For maintainers

~~- [ ] This was checked for breaking API changes and was labeled appropriately~~
~~- [ ] This includes a feature addition or change that requires a release note and was labeled appropriately~~

nnamdifrankie · 2020-01-02T13:17:09Z

@elasticmachine merge upstream

kevinlog · 2020-01-02T14:49:42Z

x-pack/plugins/endpoint/server/config.ts

+export const EndpointConfigSchema = schema.object({
+  enabled: schema.boolean({ defaultValue: false }),
+  searchResultDefaultFirstPageIndex: schema.number({ defaultValue: 0 }),
+  searchResultDefaultPageSize: schema.number({ defaultValue: 10 }),


different "entities" may want different default page sizes, such as alerts, investigations, etc.

kevinlog · 2020-01-02T14:50:15Z

x-pack/plugins/endpoint/server/index.ts


 export const config = {
-  schema: schema.object({ enabled: schema.boolean({ defaultValue: false }) }),
+  schema: EndpointConfigSchema,


good idea putting this into a separate file

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

alexk307 · 2020-01-02T16:05:10Z

x-pack/plugins/endpoint/server/types.ts

+      id: string;
+    };
+    sensor: {
+      persistence: true;


should this be boolean?

alexk307 · 2020-01-02T16:05:37Z

x-pack/plugins/endpoint/server/types.ts

+      updated_at?: Date;
+    };
+    isolation: {
+      status: false;


should this be boolean?

you can have an isolated endpoint right?

alexk307 · 2020-01-02T16:07:40Z

x-pack/plugins/endpoint/server/services/endpoint/endpoint_query_builders.ts

+      },
+      from: paging.pageIndex * paging.pageSize,
+      size: paging.pageSize,
+      index: 'endpoint-agent*',


Should this be configurable somehow?

Should this be configurable somehow?

I think we should make it conventional for now and agree what it will be called, if we make it configurable a lot of systems will have to change every time someone changes this value. fleet, endpoint generator etc. I can make it a constant.

alexk307 · 2020-01-02T16:08:29Z

x-pack/plugins/endpoint/server/services/endpoint/endpoint_query_builders.ts

+    return {
+      body: {
+        query: this.queryBody(),
+        collapse: {


why collapse? Can you leave a comment?

why collapse? Can you leave a comment?

We are technically aggregating by endpoint machine id and retrieving the latest of each group of events related to an endpoint by machine id. The collapse does this.

Sounds good, can you just paste this in the source as well?

alexk307 · 2020-01-02T16:13:26Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+      },
+      options: { authRequired: true },
+    },
+    async (context, req, res) => {


Question/DIscussion: What are the pros for using an anonymous function like this? I definitely prefer having functions named for readability purposes.

This isn't too bad because you're passing in router and only one route is being added at once, but when there are multiple routes being added it's quite hard to read IMHO.

This isn't too bad because you're passing in router and only one route is being added at once, but when there are multiple routes being added it's quite hard to read IMHO.

This handler function is only related to this route so there is the documentation. In this case I think the name may be redundant.

FYI: personally, I also like the naming on the function. One drawback of anonymous functions is debugging where you just see "anonymous" in stack traces or when doing heap/cpu profiling (but perhaps we don't do much of that, so its ok)

alexk307 · 2020-01-02T16:21:57Z

x-pack/plugins/endpoint/server/routes/endpoints.test.ts

+    expect(endpointResultList.requestPageSize).toEqual(10);
+  });
+
+  it('test find the latest of all endpoints with params', async () => {


Should we add a test with negative numbers/floats? Or does the schema enforce this?

Should we add a test with negative numbers/floats? Or does the schema enforce this?

We can enforce it in the schema.

@nnamdifrankie are we enforcing it or are you saying we could?

It is enforced by the schema https://github.com/elastic/kibana/pull/53861/files#diff-fb44c643877621f0f4e2e866c3099c52R49

jonathan-buttner · 2020-01-02T17:20:13Z

x-pack/plugins/endpoint/server/services/endpoint/endpoint_query_builders.ts

+  private readonly request: KibanaRequest<any, any, any>;
+  private readonly endpointAppContext: EndpointAppContext;
+
+  constructor(request: KibanaRequest<any, any, any>, endpointAppContext: EndpointAppContext) {


Nit: I think this could be shortened to:

constructor(private readonly request: KibanaRequest<any, any, any>, private readonly endpointAppContext: EndpointAppContext) {}

and you could remove these lines:

private readonly request: KibanaRequest<any, any, any>; private readonly endpointAppContext: EndpointAppContext;

jonathan-buttner · 2020-01-02T17:21:08Z

x-pack/plugins/endpoint/server/services/endpoint/endpoint_query_builders.ts

+    };
+  }
+
+  async paging() {


Nit: maybe make this private async paging()

jonathan-buttner · 2020-01-02T17:27:58Z

x-pack/plugins/endpoint/server/routes/endpoints.test.ts

@@ -0,0 +1,183 @@
+/*


Would it be worth creating an integration test to make sure the ES query works against real data in ES? I believe these tests just mock ES out correct?

Would it be worth creating an integration test to make sure the ES query works against real data in ES? I believe these tests just mock ES out correct?

I will add the integration test, but it is not going to replace the Unit test. They are both needed.

bkimmel · 2020-01-02T17:30:36Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+    },
+    async (context, req, res) => {
+      try {
+        const queryParams = await new AllEndpointsQueryBuilder(


I'm not sure what the best way to resolve this is (pun intended!), but I think if any one of AllEndpointsQueryBuilder, .callAsCurrentUser, or mapToEndpointResultList doesn't resolve, the catch won't fire (so neither res.ok or res.internalError will get called) and this will lock up. ~~Also, errors thrown inside those functions won't make it out to this catch (I think)~~ (it does bubble through the await). Maybe put it inside a Promise.race() with some kind of timeout?

(it does bubble through the await)

This is the expected behavior.

There is no reason that I see why they will not resolve, the client call is a rest call that eventually timeouts and fails. The other reads the config to get the default paging, am not sure if this is an issue.

oatkiller · 2020-01-02T17:08:59Z

x-pack/plugins/endpoint/server/config.ts

+import { Observable } from 'rxjs';
+import { PluginInitializerContext } from 'kibana/server';
+
+export type EndpointConfigType = ReturnType<typeof createConfig$> extends Observable<infer P>


Would you explain this? If I'm understanding this correctly, createConfig$ always returns a value that extends Observable, so the second part of this expression is unused.

I followed some other examples that are in master already, https://github.com/elastic/kibana/blob/master/x-pack/plugins/spaces/server/config.ts, https://github.com/elastic/kibana/blob/master/x-pack/plugins/security/server/config.ts

oatkiller · 2020-01-02T17:14:46Z

x-pack/plugins/endpoint/server/routes/endpoints.test.ts

@@ -0,0 +1,183 @@
+/*


Would this test be better as an API integration test? It could load an archvie (via es_archiver) and instrument the route handler and ES. This would check that the routing works and that the query works. Also it wouldn't require writing any mocking.

Would this test be better as an API integration test? It could load an archvie (via es_archiver) and instrument the route handler and ES. This would check that the routing works and that the query works. Also it wouldn't require writing any mocking.

We still need a unit test. We have an api test too but I did not want to add it to this PR to blow it up. I can add it to another PR. But I can add it if you insist.

Can you explain why you still need a unit tests? My understanding is that this test mocks various internals and asserts that they were called. My concern is that this type of test doesn't check the behavior. I'm also concerned that since its completely coupled to internals, it might break even if the behavior is correct.

Can you explain why you still need a unit tests? My understanding is that this test mocks various internals and asserts that they were called

This is what unit tests do, they test internals and expected calls on dependencies with stubs. We cannot defer all tests after the entire system is coupled together and started, without covering the units.

Thanks for adding the integration test. I agree that mocking can cause tight coupling and personally regret the places I did it in the SMP. I can see the value in stubbing out ES so you can test the translation from the search results of endpoints into the returned format done by this function mapToEndpointResultList. My suggestion (only a suggestion) would be to leave out the expects for how a function is called and how many times it is called. Like these lines:
expect(mockScopedClient.callAsCurrentUser).toBeCalledWith('search', {
const endpointResultList = mockResponse.ok.mock.calls[0][0]?.body as EndpointResultList;

and instead just validate that the results get transformed into the expected format like you're already doing.

Based on @jonathan-buttner's comment, I'm wondering if this could be replaced by one (or more) unit tests against a pure function called mapToEndpointResultList. This function could be responsible for any intricate business logic and could be tested without stubs/mocking.

A second set of API integration tests could instrument the vertical slice but with much less coverage. This approach might allow your tests to be less coupled to the implementation while also having no mocking/stubs.

I'm also arguing that unit tests don't necessarily require mocking. Here is the PR I'm working on: https://github.com/elastic/kibana/pull/53619/files

Here are my unit test files. These do not use mocks/stubs and they also test the behavior of a small unit:

x-pack/plugins/endpoint/public/embeddables/resolver/lib/matrix3.ts

x-pack/plugins/endpoint/public/embeddables/resolver/lib/transformation.test.ts

x-pack/plugins/endpoint/public/embeddables/resolver/store/camera/inverse_projection_matrix.test.ts

x-pack/plugins/endpoint/public/embeddables/resolver/store/camera/panning.test.ts

x-pack/plugins/endpoint/public/embeddables/resolver/store/camera/projection_matrix.test.ts

x-pack/plugins/endpoint/public/embeddables/resolver/store/camera/zooming.test.ts

My integration / functional tests will instrument all of the 'plumbing' that is responsible for setting up react, redux, etc. Those tests will have less coverage (they will no instrument all the branches instrumented by the unit tests.)

oatkiller · 2020-01-02T17:18:18Z

x-pack/plugins/endpoint/server/types.ts

+}
+
+export class EndpointAppConstants {
+  static ENDPOINT_INDEX_NAME = 'endpoint-agent*';


perhaps the string 'endpoint-agent*' could just be in a const variable (as opposed to a public member in a class) outside of this types module.

perhaps the string 'endpoint-agent*' could just be in a const variable (as opposed to a public member in a class) outside of this types module.

The reason is that the bootstrap also uses this value, so I wanted to put it somewhere shared. If that is fine.

@nnamdifrankie was this decided somewhere - since this is going to master shouldn't this be more finalized?

#53861 (comment)

oatkiller · 2020-01-02T17:30:26Z

x-pack/plugins/endpoint/server/plugin.test.ts

+    mockedEndpointPluginSetupDependencies = { features: mockedPluginSetupContract };
+  });
+
+  it('test properly setup plugin', async () => {


My understanding of this test is that it should check that a feature has been registered and that routes have been registered. If these behaviors were tested via API integration tests, we could test the behavior instead of checking that certain methods were called. The tests wouldn't be as coupled to the implementation details. It also wouldn't requiring writing mocks that are specific to the new platform implementation (which has been changing very frequently recently.)

How would you feel about writing an API integration test that calls one of our HTTP APIs. You could also write a test that creates a user with a certain role and then with that user checks that feature registration is working correctly by making API requests (or by asserting that elements are present in the UI.)

requiring writing mocks that are specific to the new platform implementation (which has been changing very frequently recently.)

This is actually a reason to write such test, to make it clear that the dependencies in the code are covered at a minimum. You want to detect when you code is affected by other code changes. I will add integration test.

oatkiller · 2020-01-02T17:32:32Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+      path: '/api/endpoint/endpoints',
+      validate: {
+        query: schema.object({
+          pageSize: schema.number({ defaultValue: 10, min: 1 }),


could you add comments explaining pageSize and pageIndex somewhere?

I can add that, thought it was self explanatory.

@nnamdifrankie is there an upper limit on the number of endpoints you can request in the payload?

oatkiller · 2020-01-02T17:36:56Z

x-pack/plugins/endpoint/server/services/endpoint/endpoint_query_builders.ts

+import { KibanaRequest } from 'kibana/server';
+import { EndpointAppConstants, EndpointAppContext } from '../../types';
+
+export class AllEndpointsQueryBuilder {


The paging method is only used in this class. Perhaps it would be better to make it private? Also, this class has only one method used outside of this module: toQueryParams. Since this isn't modeling an entity, and since it isn't inheriting anything, perhaps it could be changed into a function. The function could be called allEndpointsQueryParams. It could take the same arguments at the constructor currently does.

Updated the private, will leave it as a class for now as we have more querying functionality from our POC effort.

oatkiller · 2020-01-02T17:43:28Z

x-pack/plugins/endpoint/server/services/endpoint/endpoint_query_builders.test.ts

+        config: () => Promise.resolve(EndpointConfigSchema.validate({})),
+      });
+      const query = await searchQueryBuilder.toQueryParams();
+      expect(query).toEqual({


Would you explain the purpose of this test?

update the test describe

Sorry for the confusion. Could you explain what you hope to accomplish by having this test? It seems to just check the return value of a function: https://github.com/elastic/kibana/pull/53861/files/6327a4fbdde17b600f8d68d0e721e9f676f6f066#diff-0ab9ae9ab2c5fdf664d3779d6058b9a1R20

To get the collapsed list of endpoint, we have a particular query that has to be built. We are testing that the query is created as expected with certain attributes.

oatkiller · 2020-01-02T17:54:41Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+): EndpointResultList {
+  if (searchResponse.hits.hits.length > 0) {
+    return {
+      requestPageSize: queryParams.size as number,


Would you explain why you are casting values in this function? Thanks

It fails on type check hence it was cast.

I think since queryParams is typed as Record<string, unknown>, the type system doesn't understand that queryParams.size is a number. Maybe you could try changing that type to queryParams: { size: number, from: number }. This function relies on those values being numbers, so the type could reflect that.

turn out it was not needed, but in case you are wondering why it is typed as such https://github.com/elastic/kibana/blob/master/src/core/server/elasticsearch/scoped_cluster_client.ts#L67. I changed it to Record<string, any> which is the type of the for the client call

nnamdifrankie · 2020-01-02T22:39:25Z

@elasticmachine merge upstream

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

jonathan-buttner

Thanks for adding the integration test!

nnamdifrankie · 2020-01-03T16:24:50Z

@elasticmachine merge upstream

kevinlog · 2020-01-03T17:24:48Z

x-pack/plugins/endpoint/server/types.ts

+  static ENDPOINT_INDEX_NAME = 'endpoint-agent*';
+}
+
+export interface EndpointData {


a handful of these fields will likely be dropped for the first release

we will probably just need something similar to machine_id, the items under host, perhaps active_directory, policy

We can remove some items in another PR, but we likely won't be supplying all of this to start

Let talk and agree and we can remove in the next go around.

kevinlog · 2020-01-03T17:25:09Z

x-pack/plugins/endpoint/server/types.ts

+      status?: string;
+      updated_at?: Date;
+    };
+    isolation: {


likely, no isolation data for first release

kevinlog · 2020-01-03T17:26:02Z

x-pack/plugins/endpoint/server/types.ts

+    is_base_image: boolean;
+    active_directory_distinguished_name: string;
+    active_directory_hostname: string;
+    upgrade: {


like no upgrade for first release

james-elastic

comments and requesting some non happy path tests for the API

james-elastic · 2020-01-06T15:40:17Z

x-pack/plugins/endpoint/server/routes/endpoints.test.ts

+    expect(endpointResultList.requestPageSize).toEqual(10);
+  });
+
+  it('test find the latest of all endpoints with params', async () => {


@nnamdifrankie are we enforcing it or are you saying we could?

james-elastic · 2020-01-06T15:42:10Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+      path: '/api/endpoint/endpoints',
+      validate: {
+        query: schema.object({
+          pageSize: schema.number({ defaultValue: 10, min: 1 }),


@nnamdifrankie is there an upper limit on the number of endpoints you can request in the payload?

james-elastic · 2020-01-06T15:47:41Z

x-pack/plugins/endpoint/server/types.ts

+}
+
+export class EndpointAppConstants {
+  static ENDPOINT_INDEX_NAME = 'endpoint-agent*';


@nnamdifrankie was this decided somewhere - since this is going to master shouldn't this be more finalized?

james-elastic · 2020-01-06T15:48:22Z

x-pack/test/api_integration/apis/endpoint/endpoints.ts

+import { FtrProviderContext } from '../../ftr_provider_context';
+
+export default function({ getService }: FtrProviderContext) {
+  const esArchiver = getService('esArchiver');


@nnamdifrankie there are a lot of happy path tests, can you add some non happy path tests?

@james-elastic

is there an upper limit on the number of endpoints you can request in the payload?

the upper limit is bounded by elastic search which is 10000, I can add that.

was this decided somewhere - since this is going to master shouldn't this be more finalized?

We derived it from the work we did with @jonathan-buttner on the POC, so we are rolling with that.

there are a lot of happy path tests, can you add some non happy path tests?

There is not a lot of unhappy paths because there are no user inputs except for the page sizes which also has defaults if not provided. I will try to add a failure case somewhere.

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

nnamdifrankie · 2020-01-06T20:12:00Z

@elasticmachine merge upstream

james-elastic

Thanks for the updates and changes!

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

…le-saved-objects * 'master' of github.com:elastic/kibana: (86 commits) [Uptime] Added date range filter into expanded list query (elastic#52609) [SIEM] Add react/display-name eslint rule (elastic#53107) [SIEM] Enable eslint prefer-template rule (elastic#53983) Elasticsearch snapshots automation (elastic#53706) [SIEM] Enable eslint react/no-children-prop (elastic#53985) [DOCS][Reporting] Adds info about using a custom reporting index (elastic#54052) Changing background color to align with EUI color (elastic#54060) Fix linting issues (elastic#54068) NP Migration: Move doc views registry and existing doc views into discover plugin (elastic#53465) [ML] DF Analytics job creation: Add 'excludes' input field to form (elastic#53856) EMT-issue-65: add endpoint list api (elastic#53861) [SIEM] Fix doubled drag handles in Timeline (elastic#52679) Functional tests: refactor visualize_page (elastic#53845) [Dashboard] Redesign empty screen in readonly mode (elastic#54073) [ML] Support search for partitions on Single Metric Viewer (elastic#53879) update apm index pattern (elastic#54095) Add data ui for envoyproxy Metricbeat Module (elastic#53476) [ML] persist the brush when expanded to full width (elastic#54020) Skip failing test (elastic#54100) [APM] Show errors on the timeline instead of under the transaction (elastic#53756) ... # Conflicts: # src/legacy/core_plugins/console/public/np_ready/application/contexts/services_context.tsx # src/legacy/core_plugins/console/public/np_ready/application/index.tsx

…/kibana into feature/console-saved-objects * 'feature/console-saved-objects' of github.com:jloleysens/kibana: (86 commits) [Uptime] Added date range filter into expanded list query (elastic#52609) [SIEM] Add react/display-name eslint rule (elastic#53107) [SIEM] Enable eslint prefer-template rule (elastic#53983) Elasticsearch snapshots automation (elastic#53706) [SIEM] Enable eslint react/no-children-prop (elastic#53985) [DOCS][Reporting] Adds info about using a custom reporting index (elastic#54052) Changing background color to align with EUI color (elastic#54060) Fix linting issues (elastic#54068) NP Migration: Move doc views registry and existing doc views into discover plugin (elastic#53465) [ML] DF Analytics job creation: Add 'excludes' input field to form (elastic#53856) EMT-issue-65: add endpoint list api (elastic#53861) [SIEM] Fix doubled drag handles in Timeline (elastic#52679) Functional tests: refactor visualize_page (elastic#53845) [Dashboard] Redesign empty screen in readonly mode (elastic#54073) [ML] Support search for partitions on Single Metric Viewer (elastic#53879) update apm index pattern (elastic#54095) Add data ui for envoyproxy Metricbeat Module (elastic#53476) [ML] persist the brush when expanded to full width (elastic#54020) Skip failing test (elastic#54100) [APM] Show errors on the timeline instead of under the transaction (elastic#53756) ...

kibanamachine · 2020-01-09T18:13:58Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: 0686689

History

💚 Build #18249 succeeded 0686689
💔 Build #18227 failed ac81bae
💔 Build #18195 failed 0be7a08
💚 Build #17816 succeeded 7718594
💔 Build #17786 failed 06ba203

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

paul-tavares

Hi @nnamdifrankie - thanks for getting this through.
I was at x-school last week and just got a chance to review it and posted my comments (all optional).

paul-tavares · 2020-01-13T20:20:01Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+  _source: EndpointData;
+}
+
+export interface EndpointResultList {


Sorry I'm late - was getting x-schooled last week.

Should we move this to server/types.ts? Would be good for the FE to use it as well when typing up the API response.

I will consider this and probably put a small PR out.

paul-tavares · 2020-01-13T20:23:14Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+      validate: {
+        body: schema.nullable(
+          schema.object({
+            paging_properties: schema.arrayOf(


I was wondering why the paging_properties is an Array<Object>. Would it be simpler to define it as an object with shorter options names:

{ paging: { size: number, page: number } }

I made the change because for some reason the order of property mattered. So size will always have to come before page, else it would be ignored. I also wanted validation from the schema too. I gave it a shot and this was the compromise.

Thanks @nnamdifrankie .
That seems weird - is that perhaps an issue with the new platform that we're using? If you think it is, maybe report it to the Kibana platform team (slack channel #kibana-platform )

paul-tavares · 2020-01-13T20:29:55Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+                  page_size: schema.number({ defaultValue: 10, min: 1, max: 10000 }),
+                }),
+                // the index of the page to return
+                schema.object({ page_index: schema.number({ defaultValue: 0, min: 0 }) }),


if I read the code correctly, page_index is zero-based. For simplicity, should it be 1-based? (which mean it would be a pass-through to the elasticsearch from option)?

Well, the from field is 0 based, so your first page is 0 to page size.

paul-tavares · 2020-01-13T20:42:00Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+      },
+      options: { authRequired: true },
+    },
+    async (context, req, res) => {


FYI: personally, I also like the naming on the function. One drawback of anonymous functions is debugging where you just see "anonymous" in stack traces or when doing heap/cpu profiling (but perhaps we don't do much of that, so its ok)

paul-tavares · 2020-01-13T20:48:43Z

x-pack/plugins/endpoint/server/routes/endpoints.ts

+  // the page size requested
+  request_page_size: number;
+  // the index requested
+  request_index: number;


For consistency, could this match the name of the paging input param? (request_page_index)

* Add Endpoint plugin and Resolver embeddable (#51994) * Add functional tests for plugins to x-pack (so we can do a functional test of the Resolver embeddable) * Add Endpoint plugin * Add Resolver embeddable * Test that Resolver embeddable can be rendered Conflicts: x-pack/.i18nrc.json x-pack/test/api_integration/apis/index.js * [Endpoint] Register endpoint app (#53527) * register app, create functional test * formatting * update tests * adjust test data for endpoint * add endpoint tests for testing spaces, app enabled, disabled, etc * linting * add read privileges to endpoint * rename variable since its used now * remove deprecated context * remove unused variable * fix type check * correct test suite message Co-Authored-By: Larry Gregory <[email protected]> Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Larry Gregory <[email protected]> * [Endpoint] add react router to endpoint app (#53808) * add react router to endpoint app * linting * linting * linting * correct tests * change history from hash to browser, add new test util * remove default values in helper functions * fix type check, use FunctionComponent as oppsed to FC * use BrowserRouter component * use BrowserRouter component lin * add comments to test framework, change function name to include browserHistory Co-authored-by: Elastic Machine <[email protected]> * EMT-issue-65: add endpoint list api (#53861) add endpoint list api * EMT-65:always return accurate endpoint count (#54423) EMT-65:always return accurate endpoint count, independent of paging properties * Resolver component w/ sample data (#53619) Resolver is a map. It shows processes that ran on a computer. The processes are drawn as nodes and lines connect processes with their parents. Resolver is not yet implemented in Kibana. This PR adds a 'map' type UX. The user can click and drag to pan the map and zoom using trackpad pinching (or ctrl and mousewheel.) There is no code providing actual data. Sample data is included. The sample data is used to draw a map. The fundamental info needed is: process names the parent of a process With this info we can topologically lay out the processes. The sample data isn't yet in a realistic format. We'll be fixing that soon. Related issue: elastic/endpoint-app-team#30 * Resolver test plugin not using mount context. (#54933) Mount context was deprecated. Use core.getStartServices() instead. * Resolver nonlinear zoom (#54936) * [Endpoint] add Redux saga Middleware and app Store (#53906) * Added saga library * Initialize endpoint app redux store * Resolver is overflow: hidden to prevent obscured elements from showing up (#55076) * [Endpoint] Fix saga to start only after store is created and stopped on app unmount (#55245) - added `stop()`/`start()` methods to the Saga Middleware creator factory - adjust tests based on changes - changed application `renderApp` to stop sagas when react app is unmounted * Resolver zoom, pan, and center controls (#55221) * Resolver zoom, pan, and center controls * add tests, fix north panning * fix type issue * update west and east panning to behave like google maps * [Endpoint] FIX: Increase tests `sleep` default duration back to 100ms (#55492) Revert `sleep()` default duration, in the saga tests, back to 100ms in order to prevent intermittent failures during CI runs. Fixes #55464 Fixes #55465 * [Endpoint] EMT-65: make endpoint data types common, restructure (#54772) [Endpoint] EMT-65: make endpoint data types common, use schema changes * Basic Functionality Alert List (#55800) * sets up initial grid and data type * data feeds in from backend but doesnt update * sample data feeding in correctly * Fix combineReducers issue by importing Redux type from 'redux' package * Add usePageId hook that fires action when user navigates to page * Strict typing for middleware * addresses comments and uses better types * move types to common/types.ts * Move types to endpoint/types.ts, address PR comments blah 2 Co-authored-by: Pedro Jaramillo <[email protected]> * [Endpoint] Add Endpoint Details route (#55746) * Add Endpoint Details route * add Endpoint Details tests * sacrifices to the Type gods * update to latest endpoint schema Co-authored-by: Elastic Machine <[email protected]> * [Endpoint] EMT-67: add kql support for endpoint list (#56328) [Endpoint] EMT-67: add kql support for endpoint list * [Endpoint] ERT-82 ERT-83 ERT-84: Alert list API with pagination (#56538) * ERT-82 ERT-83 ERT-84 (partial): Add Alert List API with pagination * Better type safety for alert list API * Add Test to Verify Endpoint App Landing Page (#57129) Conflicts: x-pack/test/functional/page_objects/index.ts * fixes render bug in alert list (#57152) Co-authored-by: Elastic Machine <[email protected]> * Resolver: Animate camera, add sidebar (#55590) This PR adds a sidebar navigation. clicking the icons in the nav will focus the camera on the different nodes. There is an animation effect when the camera moves. Conflicts: yarn.lock * [Endpoint] Task/basic endpoint list (#55623) * Adds host management list to endpoint security plugin Co-authored-by: Elastic Machine <[email protected]> * [Endpoint] Policy List UI route and initial view (#56918) * Initial Policy List view * Add `endpoint/policy` route and displays Policy List * test cases (both unit and functional) Does not yet interact with API (Ingest). * Add ApplicationService app status management (#50223) This was already backported, but changes to endpoint app could not be backported, since endpoint app itself hadn't been backported. Now that the endpoint app is backported, reapply the endpoint specific changes from the original commit. * Implements `getStartServices` on server-side (#55156) This was already backported, but changes to endpoint app could not be backported, since endpoint app itself hadn't been backported. Now that the endpoint app is backported, reapply the endpoint specific changes from the original commit. * [ui/utils/query_string]: Remove unused methods & migrate apps to querystring lib (#56957) This was already backported, but changes to endpoint app could not be backported, since endpoint app itself hadn't been backported. Now that the endpoint app is backported, reapply the endpoint specific changes from the original commit. Co-authored-by: Kevin Logan <[email protected]> Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Larry Gregory <[email protected]> Co-authored-by: nnamdifrankie <[email protected]> Co-authored-by: Davis Plumlee <[email protected]> Co-authored-by: Paul Tavares <[email protected]> Co-authored-by: Pedro Jaramillo <[email protected]> Co-authored-by: Dan Panzarella <[email protected]> Co-authored-by: Madison Caldwell <[email protected]> Co-authored-by: Charlie Pichette <[email protected]> Co-authored-by: Candace Park <[email protected]> Co-authored-by: Pierre Gayvallet <[email protected]> Co-authored-by: Alexey Antonov <[email protected]>

nnamdifrankie added 2 commits December 30, 2019 21:06

add endpoint list api

08343b2

Merge branch 'master' into emt-issue-65_add-endpoint_list_api

2e70a4c

nnamdifrankie added release_note:skip Skip the PR/issue when compiling release notes v7.6.0 v8.0.0 labels Jan 2, 2020

Merge branch 'master' into emt-issue-65_add-endpoint_list_api

7dfb50a

kevinlog reviewed Jan 2, 2020

View reviewed changes

nnamdifrankie added 2 commits January 2, 2020 10:26

prefix property with endpoint

91bfbd3

Merge branch 'emt-issue-65_add-endpoint_list_api' of github.com:nnamd…

4ecfbf2

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

alexk307 reviewed Jan 2, 2020

View reviewed changes

review comments changes

6327a4f

jonathan-buttner reviewed Jan 2, 2020

View reviewed changes

bkimmel reviewed Jan 2, 2020

View reviewed changes

oatkiller reviewed Jan 2, 2020

View reviewed changes

add integration test, add more comments on properties and test

cad4f76

elasticmachine and others added 4 commits January 2, 2020 14:39

Merge branch 'master' into emt-issue-65_add-endpoint_list_api

2b01cf5

add more comments, change query params type

42e4f07

Merge branch 'emt-issue-65_add-endpoint_list_api' of github.com:nnamd…

b6ca98f

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

remove accent from description

06ba203

jonathan-buttner approved these changes Jan 3, 2020

View reviewed changes

Merge branch 'master' into emt-issue-65_add-endpoint_list_api

7718594

kevinlog reviewed Jan 3, 2020

View reviewed changes

james-elastic requested changes Jan 6, 2020

View reviewed changes

nnamdifrankie added 2 commits January 6, 2020 15:04

add more testing, use more function

18aaa7b

Merge branch 'emt-issue-65_add-endpoint_list_api' of github.com:nnamd…

13fe43a

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

Merge branch 'master' into emt-issue-65_add-endpoint_list_api

0be7a08

james-elastic approved these changes Jan 6, 2020

View reviewed changes

nnamdifrankie added 3 commits January 6, 2020 16:24

fix type check

b8ed0e8

Merge branch 'emt-issue-65_add-endpoint_list_api' of github.com:nnamd…

ac81bae

…ifrankie/kibana into emt-issue-65_add-endpoint_list_api

fix type check, fix api variable case

0686689

nnamdifrankie merged commit 6a2fb61 into elastic:master Jan 7, 2020

nnamdifrankie deleted the emt-issue-65_add-endpoint_list_api branch January 7, 2020 15:02

kevinlog changed the title ~~EMT-issue-65: add endpoint list api~~ [Endpoint] EMT-issue-65: add endpoint list api Jan 9, 2020

kevinlog added Team: Endpoint Management Team:Endpoint Data Visibility Team managing the endpoint resolver Team:Endpoint Response Endpoint Response Team labels Jan 9, 2020

paul-tavares reviewed Jan 13, 2020

View reviewed changes

kevinlog added the Feature:Endpoint Elastic Endpoint feature label Feb 18, 2020

[Endpoint] EMT-issue-65: add endpoint list api #53861

[Endpoint] EMT-issue-65: add endpoint list api #53861

Conversation

nnamdifrankie commented Dec 31, 2019 • edited Loading

Summary

Checklist

For maintainers

nnamdifrankie commented Jan 2, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnamdifrankie Jan 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnamdifrankie Jan 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bkimmel Jan 2, 2020 • edited Loading

Choose a reason for hiding this comment

nnamdifrankie Jan 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnamdifrankie Jan 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnamdifrankie Jan 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnamdifrankie Jan 6, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnamdifrankie commented Jan 2, 2020

jonathan-buttner left a comment

Choose a reason for hiding this comment

nnamdifrankie commented Jan 3, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

james-elastic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnamdifrankie commented Dec 31, 2019 •

edited

Loading

nnamdifrankie Jan 2, 2020 •

edited

Loading

nnamdifrankie Jan 2, 2020 •

edited

Loading

bkimmel Jan 2, 2020 •

edited

Loading

nnamdifrankie Jan 2, 2020 •

edited

Loading

nnamdifrankie Jan 2, 2020 •

edited

Loading

nnamdifrankie Jan 2, 2020 •

edited

Loading

nnamdifrankie Jan 6, 2020 •

edited

Loading