This particular flow uses deployment manager to create a VM with the cloud logging agent and the corresponding auditd config to emit the structured logs.
You don’t ofcourse have to use deployment manager but if all you want out of this is the startup script on a debian VM I used, here it is:
The remaining bits describes a turn-key installation using deployment manager…its easy; i’d ask you to try it out.
First configure the compute service account IAM access to Cloud Logging. To do this, find the compute engine service account and set the IAM “Log Writer” Role.
vm_template.jinja (source at end of the article) and set it to use your compute service account:
properties: zone: us-central1-a serviceAccount: YOUR_SVCemail@example.com serviceAccountScopes: - https://www.googleapis.com/auth/logging.write
then deploy using GCP deployment manager as usual
$ gcloud deployment-manager deployments create auditd-monitor --config cluster.yaml
(the DM script i used here is at the end of the article)
Now test it out:
SSH to the VM and run a privileged command
…wait ~3minutes or so after the deployment manger script ends…the startup script will need to finish up. Once thats done, ssh in:
# gcloud compute ssh auditd-monitor-my-vm-vm --zone=us-central1-a
then try to edit the hosts file:
$ sudo vi /etc/hosts
You should see detailed log entries for the ssh session
and also about the sudo command you just ran:
Note the auditd’s default logging is just key=value pairs space separated per event. For GCP’s logging system to understand it has structure, we need to emit a log line as JSON.
The following fluentd parser extracts key=value pairs space-delimited into JSON:
/opt/google-fluentd/embedded/bin/gem install fluent-plugin-kv-parser
This is the good stuff: ..on the VM’s cloud logging area, you should see a log name audit which contains the json parsed messages emitted by auditd the following shows a privleged command:
And a Filter for a specific syscall for a given uid=1000
Note: its rendered as
JSONPayload which means you can easily create a log-to-metric, search, transform, etc. Its far, far better than
auditd emits its data as
As you can see, a lot of data gets generated by auditd. You are free to tune how much auditd emits pretty easily by modifying auditd’s config file at anytime. In the example here, i intentionally enabled verbose logging anytime a user uid=0 executed a command (i.,e
“-F euid=0 -S execve”)
Thats it…you’re now getting (a lot) of log events automatically parsed by and displayed in cloud logging.