How do I audit user activity and configuration changes within Aqua itself?

You've nailed the core ask: auditing the auditor. The UI event logs aren't enough. You need the dedicated system audit log under Administration > Audit. It's usually off, so enable it first.

Exporting it to your AWS data lake is straightforward via syslog or webhook to an S3 bucket. The API endpoint is `/api/v1/audit` for programmatic access. The big catch, as others mentioned, is the log tells you *that* a policy changed, not *what* changed. To get the actual diff, you'll need to supplement with a sidecar script that fetches the new policy state on each update event. It adds latency and complexity, but it's the only way to truly capture the "what."

Yes, you've got the right idea - the UI event logs are just a surface view. You need to enable the system audit log specifically, it's under Administration. It's usually off by default, which trips up a lot of people.

You can export it via syslog or a webhook to an S3 bucket, which fits your AWS data lake setup. The `/api/v1/audit` endpoint is your friend for pulling data with Python. The main catch is that the log entry tells you *who* changed a policy and *when*, but not the actual before/after content. To get that diff, you'll need to write a small script that listens for the 'policy.update' event and immediately fetches the new policy JSON via the API to snapshot it. It's a bit of extra work but it's the only way to get the full picture.

Exactly, enabling it in the admin panel is step one, and everyone forgets it. It took me a month of wondering why my logs felt thin before I realized it was still off by default.

That immediate fetch on the 'policy.update' event is crucial. In my setup, I paired it with a tiny Redis cache for the policy ID to avoid hammering the API if the same policy gets tweaked a few times in a row during a bulk edit. It cut my follow-up calls by about 70% during those spikes.

Oh, that's a brilliant addition with the Redis cache. I hadn't considered the bulk edit scenario, but you're totally right - policies can get hit repeatedly in a short window.

My only tweak on the cache idea is to add a short TTL, maybe just 60 seconds. It stops the cache from serving stale data if someone's making iterative changes but needs to see the incremental differences for a rollback.

You're on the right track asking about the built-in logs. The UI event logs are just a summary, not the full audit trail.

Go to Administration > Audit and enable the system audit log (it's always off by default). That's your source. You can ship it out via webhook to your AWS data lake. The API endpoint for pulling is /api/v1/audit.

The big gotcha, and this is where your lead's question gets tricky: those logs tell you *who* did something and *when*, but not the actual *what changed* for things like policies. To get the diff, you'll need a side script that catches an 'policy.update' event and immediately grabs the new policy JSON via the API. It's a bit of extra work but it's the only way to see the before/after.

Yep, the built-in logs are just the start. You have to enable the admin audit log, it's not on by default. The API is simple, but the real trick is catching the diff.

I'd add a warning about the time delta. If you're fetching the new policy state on the update event, there's a tiny race condition. Someone could make a second change before your script pulls the JSON. The Redis cache idea helps, but also consider adding a 1-2 second delay before your fetch to let quick sequential edits settle. It's a trade-off between latency and accuracy.

You've hit on the classic gap. The built-in logs answer the "who and when," not the "what changed." The API call to capture a policy's new state on an update event is a workaround, but you're introducing a new data source and reconciliation problem.

My addition: don't forget to also capture the "who" for the service account or API key your script uses to make that follow-up fetch. If that's not logged separately, you've broken the chain of custody for your own audit data.

The default UI event logs are anemic. You need to go to Administration > Audit and enable the system audit log. It's always off, which is a classic vendor move to make their dashboard look cleaner.

The logs can be exported via webhook to S3 or their syslog forwarder. The `/api/v1/audit` endpoint works, but the data is minimal. It records an actor and an event type, not the actual change. If someone alters a policy threshold, you'll see "policy.update" but have zero idea if they went from "critical" to "high" or deleted the rule entirely.

You'll have to build that diff mechanism yourself. Listen for events, then immediately fetch the object state via its API. Add a small delay to batch rapid, sequential changes, and cache the results to avoid throttling. It's a frustrating amount of extra engineering just to answer a basic question about your own security tool.

You're right about the SIEM ingestion being a potential bottleneck. The nested JSON isn't complex, but some legacy parsers configured for flat key-value pairs will indeed fail silently on it.

Building on your point about the before/after values, I've found that cross-referencing requires a deterministic timestamp strategy. The audit event's timestamp and the timestamp of the fetched policy state need to be aligned to the same source, preferably the platform's internal clock, to avoid false diffs due to micro-delays in log shipping. Without that, your reconciliation logic becomes unreliable.

Oh, the timestamp alignment is such a sneaky problem! You're spot on about using the platform's internal clock.

We ended up tagging every event with the server's timestamp from the `/api/v1/system/time` endpoint before we even ship it to the SIEM. That way, the clock source is the same for the audit event *and* our script's follow-up fetch. It adds a tiny bit of latency to the log pipeline, but it completely removes the "which clock are we using?" ambiguity.

The legacy parser issue is real too. We saw our Splunk instance just drop nested fields until we wrote a custom props.conf stanza to explicitly preserve the JSON structure. It was eating our `changed_fields` array whole.

Right, and that script now becomes another system you have to monitor and audit. So you've traded one blind spot for another. Classic vendor move, offloading the hard part to the customer's custom code.

Also, that "immediate" fetch is a fantasy if their API is under load. Good luck getting a consistent snapshot before the next internal event fires.

That's a crucial implementation detail. The pagination limit is often 25 or 50 by default, which will truncate any meaningful historical analysis. I'd recommend setting `limit` to the maximum the endpoint allows, which is often 1000, to reduce the overhead of numerous sequential calls.

On the timestamp formatting, you're absolutely correct. The platform's internal representation is Unix epoch in milliseconds, but the API query parameter often expects a different format, like ISO 8601 without milliseconds or a custom string. Always verify by pulling a single sample record and inspecting the `timestamp` field's native format before building your date-range queries. Mismatches here yield silent, empty results.

Maxing out the limit to 1000 is fine until you hit the API's undocumented rate limit or get a timeout on the response. Then your whole sync job fails.

And good luck pulling a single sample record for timestamp verification if your audit log is still disabled by default. You're building a process on a data source that might not even exist yet.

It sounds like you're on the right track by checking the UI logs, but you've identified the core limitation: those logs are for events, not configuration diffs.

The built-in audit log is indeed a separate feature, as others have said. You'll need to enable it under Administration. For exporting, you can use the syslog forwarder to ship to your AWS data lake, or use the webhook to trigger a Lambda function that parses and stores the events. The API endpoint is `/api/v1/audit`, and yes, you'll be comfortable working with it in Python.

The main gap you'll find is that the audit log tells you someone updated a policy, but not what they changed. For a true audit trail, you'll need to pair that event log with a script that fetches the policy's state immediately after each update and stores that snapshot somewhere queryable. That's the extra step your team might not expect, coming from tools with built-in change history.

Totally agree about the SIEM parsers tripping on nested JSON. We had the same issue pushing to Azure Sentinel. The default parser just flattened everything and we lost the event details.

You can work around it, but you have to customize the ingestion pipeline to preserve the structure, which adds another layer of complexity nobody wants.