/lgtm

/approve no-issue

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: crassirostris, piosz

Associated issue requirement bypassed by: crassirostris

The full list of commands accepted by this bot can be found here.

/retest

/test all [submit-queue is verifying that this PR is safe to merge]

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here..

@crassirostris, may I ask what the new approach is? We're using a downstream version of the same config across clouds directing our logs to Stackdriver so we just want to be aware of whatever the new approach is so we can update appropriately.

@c-knowles Take a look at https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

@crassirostris thanks! I take it that means a switch to the webhook backend for GKE. I've been digging around to figure out if that'll be supported by non-GCP clouds or we have to have different approaches now.

@c-knowles Sorry, what I meant in this PR is that basic auditing is deprecated, but advanced auditing or just auditing can be used now with the old approach, you can just consume JSONs from the audit log file. There are example of configuring logging agent to do just that in the article I linked above

@crassirostris ok thanks. We'll use that for now. I don't have much visibility on advanced auditing and what's to come but I'm also working on the kube-aws project so would like a sensible default there (it defaults to file output right now). I take it the deprecation here means for GKE and perhaps it uses some other mechanism or a flag value of - for stdout. BTW, if there is a better place for this I'm happy to post it elsewhere.

@c-knowles No, deprecation happened on the Kubernetes level. There used to be an old mechanism for auditing and now there's a completely new one, grasped in the following design proposal, old one is (being) removed from Kubernetes altogether

@crassirostris thanks for the design link, it will be very useful for me. I understand there's a new mechanism just I thought the addon code was the base fluentd config for kubernetes, at least on GKE/GCP. I could have missed something in the recent updates but in the base fluentd config after this PR it appears there's nothing which covers audit logs at all? Maybe my question should have been whether the overall plan is to document example fluentd config only on kubernetes.io instead of in addons source?

@c-knowles

in the base fluentd config after this PR it appears there's nothing which covers audit logs at all?

Yes, that's intended. The approach here is that config is not set in stone, it's intended to be changed for each concrete case. E.g. in GKE environment audit logs are collected using webhook, so there's no need to configure logging agent

the overall plan is to document example fluentd config only on kubernetes.io instead of in addons source?

Yes, you can say that

@crassirostris great, thank you.