Support SIGHUP logrotation for audit (and other logs)

[tcolgate]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

At present the audit logs do not support traditional log rotation, making it harder to manage over time.

What would the ideal solution look like to you?

It would be good to support traditional SIGHUP log rotation, or more advanced log rotation mechanism (e.g. as covered in the ZAP FAQ, https://github.com/uber-go/zap/blob/master/FAQ.md#does-zap-support-log-rotation)

Anything else?

No response

[MarcoJanecki]

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? :)

[charithe]

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.

[tcolgate]

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.

[MarcoJanecki]

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. :)

[charithe]

@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.