System Audit Logs
Endpoints for monitoring Veza user activity
Operation | Syntax |
---|---|
GET /api/preview/system/audit | |
GET /api/preview/system/audit/export |
Audit Logs record every API call, providing a record of actions conducted within Veza. Depending on your use case, you can export a continuous list of events, or get events matching a filter in chronological order. Developers, administrators, and security teams can use these requests to:
Integrate Veza with an SIEM platform or other auditing tools
Detect potential inappropriate access or usage
Get insight into how users are interacting with the Veza platform
See Audit events for more details about the audit event object.
Pagination
Responses will include a next_page_token
. Use this page_token
in the request query to get the next batch of results.
Setting a page size is required for requests. The maximum page size is currently 10,000 records.
List audit events
This endpoint supports filtering by ended_at
timestamp, method
, user_id
, and url
. Results are ordered by time completed.
A timestamp filter is always required. The API allows querying events for up to 90 days in the past.
Example:
Export audit events
Returns a paginated list of events, intended for exporting entries into an external log management system.
To ingest events as they become available without skipping any entries, first make call with a persisted_at GE "TIMESTAMP"
filter. Then, continuously call the next page. The export endpoint can return the error code ResourceExhaused
. If encountered, clients should wait for a minute before retrying the request.
Example:
Question: If a customer includes the persisted_at
timestamp hard-coded in a script, and Veza only exports events for 1 month, what happens after a month?
Answer: The persisted_at
parameter is ignored if you send a page_token
in the API call. It won’t matter if the date is more than 90 or 30 days in the past.
Audit events
An event describes an API-level action, including the IP address and user agent of the caller. Requests can originate from user sessions, or from applications using API keys. The following is a sample event for a successful API key generation:
Identity
Field | Description |
---|---|
| Unique user identifier. |
| Unique session identifier. |
| Unique identifier of an API key. |
| User email address. |
Status
Field | Description |
---|---|
| gRPC code indicating request status. |
| HTTP status code of the response. |
| Details about a bad request. |
Client
Field | Description |
---|---|
| Client IP address. |
| Client user agent string. |
Event
Field | Description |
---|---|
| The API endpoint that was accessed. |
| The HTTP method used for the request. |
| The URL of the request. |
| The unique identifier for the request. |
| The contents of the API request. |
| Excerpt of the API response. |
| RFC 3339 timestamp when the event started. |
| RFC 3339 timestamp when the event ended. |
request
andresponse
both only contain some whitelisted fields. Due to size limitations, the entire message is not recorded.
Last updated