[Too]

Log shipping is usually based on tailing a file on disk in a separate process. Eg FileBeat, Fluentd, Promtail, logrotate.

Separation of concerns. Keeps infrastructure details out of your app and is more likely to at least leave a trace on disk in case the central logging goes south, when you need it the most.

On demand changing of log levels is still something worth keeping in application, depending on your verbosity volumes.

[kbart]

Fair enough, but that's more of how you package things - you can either have a separate class in Java inside your jar or you can have a standalone agent application (often also yet another Java application), but the attack surface doesn't change much. If log4j would be a standalone agent running on the same application server with this RCE vulnerability, the end result would be exactly the same.

[Too]

Didn’t mean to split the log shipper for sake of security but since you brought it up :) RCE in the app allows reading secrets the application holds in memory, a lot more difficult from another process. And if you run the log scraper in a less privileged container you could restrict the blast radius to basically nothing except shipping fake logs to the central system.

But sure, take this reasoning too far and you end up with micro service spaghetti, so some balance is needed.

[kbart]

While in theory you can, I'm yet to see a proper defense in depth implementation despite having >10 years in the industry. In my book, if you get shell access to pod, it's game over, as these secrets in program's memory are probably also available as environmental variables, accessible in k8s Secrets etc., not to mention other ways to compromise an underlying node and the whole cluster.. But yes, this is already too far from the original topic.