Support SIGHUP logrotation for audit (and other logs) about cerbos HOT 5 CLOSED

@MarcoJanecki thanks for the explanation. That's indeed a frustrating situation. I am not familiar with Azure but a quick search suggests that Azure Logic Apps can export data from LAW to a storage account (https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-export-logic-app). Is that something you might be able to get access to?

We'll look into the possibility of adding multiple audit destinations. However, as I mentioned above, it has some performance overhead so I can't guarantee that we'll definitely be able to support it in the near term.

from cerbos.

Hey :)
It would be very nice, if it would be also included, that audit log output to multiple sources is supported.
We currently face an issue, where we somehow need to have the audit logs printed to stdout and path/to/file.log. Is this something which is sensible to do in one task if already working on the actual log file path? :)

from cerbos.

Could you provide more information about your use case? Audit logging has a little bit of overhead so that's why we try to keep that path as lean as possible. Typically a log collector would either scrape the stdout/stderr of the process or read from a particular file so I am curious to understand why you need both.

from cerbos.

We currently face an issue, where we somehow need to have the audit logs printed to stdout and path/to/file.log

You can possibly achieve that by piping through tee.

from cerbos.

Hey :)
So basically the problem is, that we have to deploy to an infrastructure we have very few control of.
We have been provided a Microsoft Azure environment including KeyVault, DB, Log analytics workspace (LAW), StorageAccount, etc... and an AKS cluster (Kubernetes).
The providing team has the whole infrastructure (at least outside the AKS cluster) under its control and we have barely any rights to change anything.

Diving deeper into the actual problem:
The infrastructure team only set up the LAW to gather information from a Pod's stdout/stderr. But the LAW retains logs only for 30 days due to costs, etc. The StorageAccount's in turn, the LAW can not query on.
By legal regulations, we need to store audit logs for many years in a persistent storage.

Thus, currently we have to decide to either:

• Store audit logs long-term in a FileShare of a StorageAccount to fulfill legal requirements
• Put to stdout to have it available in the LAW in order to be able to query/monitor/analyze recent logs

So to summarize my problem: That is not a technical blocker. But in environments, where you do not have everything under your own control, that would be a feature that would be (at least for us) very handy. :)

from cerbos.