Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracee API server #2991

Closed
4 tasks done
yanivagman opened this issue Apr 9, 2023 · 3 comments
Closed
4 tasks done

Tracee API server #2991

yanivagman opened this issue Apr 9, 2023 · 3 comments

Comments

@yanivagman
Copy link
Collaborator

yanivagman commented Apr 9, 2023

This issue was already discussed in previous issues (#636, #1726), however, Tracee recently changed its architecture to be based on one binary and introduced policies which affects the way this API server should look like.

The goal is simple - allow configuring Tracee in runtime. In addition, the server may expose other functionalities in the future, such as getting statistics from Tracee and a stream of the events output.

To breakdown the work, the following steps should be taken (a separate issue can be opened for each):

  • Define an API that will be exposed by Tracee. The API shuold allow adding/removing/modifiying policies in runtime, getting statistics, and potentially getting a stream of events
  • Map required changes. Dynamically changing policies in runtime will require a lot of changes, such as adding/remvoing events in runtime, updating bpf maps, attaching events to probes and more. Also, we will need to invalidate some caches (e.g. the matched_scopes field in the bpf task_info_map will need to be invalidated) - we need to map all the required changes and think about the design
  • Implementing the API. After thinking about the API and required changes, we can start moving to the dirty part. This part will need to be broken into steps, according to the design we got from the previous steps.
  • Implementing the server (probably using GRPC), which will use the API we implemented in the previous step
@josedonizetti
Copy link
Contributor

The lastest chat we had, we came up with a possible v1 implementation of the API for the next version

service Tracee {
    rpc ListEventsDefinition(ListEventsDefinitionRequest) returns (ListEventsDefinitionResponse) // List events definitions, with their metadata
    rpc StreamEvents(StreamEventsRequest) returns (stream Event) // streams of events, which is dynamically changed by either delete or update policy. Eg: if you disable a policy it would affect a opened stream

    rpc DeletePolicy(PolicyName) returns (Empty) // dropping the event
    rpc UpdatePolicy(UpdatePolicy) returns (Policy) // enable and disable policy, or enable/disable event globally
    rpc Version() // returns tracee version
}

@josedonizetti josedonizetti mentioned this issue Jul 23, 2023
13 tasks
@josedonizetti
Copy link
Contributor

josedonizetti commented Jul 23, 2023

As this issue is an EPIC which will probably exist for a few releases, I've created an issue for the API v1 we want to release on 0.18.0 -> #3208

@yanivagman yanivagman modified the milestones: v0.18.0, v0.19.0 Aug 1, 2023
@yanivagman yanivagman modified the milestones: v0.19.0, v0.20.0 Sep 28, 2023
@itaysk itaysk removed this from the v0.20.0 milestone Nov 20, 2023
@yanivagman
Copy link
Collaborator Author

Since we already implemented a first iteration of the API in #3208 and we have a dedicated issue for dynamic policy modification in #3239, I think we can close this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants