Configuration

Auditing is configurable at two levels:

Policy : What is recorded.

: What is recorded. Backends: How are records persisted and broadcast.

This is a basic policy that would log everything at the Metadata level.

The policy below was created for GCE, but it’s a great starting point for an audit policy. It is much less verbose than the simple audit policy above, which can be costly if you’re using a SaaS centralized logging solution.

Something to note about audit policies is that when an event is processed it is compared against the audit policy rules in order, and the first matching rule sets the audit level of the event. It’s pretty weird. It would make a lot more sense to read the entire policy and apply rules according to most restrictive; like is done with Kubernetes RBAC policies.

Once we’ve defined a policy like above, we need to apply it to the Kubernetes API Server.

For Kops, we can apply the changes with kops edit cluster <cluster> .

NOTE: If you’re using a cluster management tool other than Kops, you’ll need to find some way to get the audit policy on the Kubernetes master node.

In the kube configuration above, we’re using a log backend, to read about log backends and webhook backends, check the official Kubernetes documentation.

OK! Once we’ve rotated our master node with the new configuration, we can pickup the audit logs from the auditLogPath using some kid of log exporter and send them to a centralized logging solution. My preference is LogDNA.

You should be getting some pretty audit logs now. Have fun!