andrewlow
commented
5 years ago There is one line of code that is responsible for emitting the audit log data
console.log(JSON.stringify(data.items[i]));The AT service is built on top of LogDNA. Audit logs are 'just log data' and can easily be stored in a LogDNA account. The IBM Cloud is capturing all of the audit data from IBM services and sharing it wth customers via a LogDNA instance that is isolated for audit data.
We can make use of the Node.js library to forward data. This should be a relatively simple change to app.js.
When visiting the IBM Cloud web interface for AT the ingestion token is not shown to the user.
However, if we visit the LogDNA user interface and manage the API keys, then the ingestion key is visible to us.
Thus we have all the parts we need to send data from this webhook target to Activity Tracker.
The code app.js currently simply drop the data that comes from the audit log webhook on stdout - assuming that there is a logging agent that will pick up the container output and forward to the logging service.
The IBM Cloud Activity Tracker with LogDNA service is the audit service provided by IBM Cloud. User actions against cloud resources are automatically sent to the service providing an audit trail.
There is some debate if kube audit logs should be stored in the Activity Tracker (AT) service or not. Currently audit-events that are sent to AT are generated exclusively by IBM services operating on resources on behalf of a customer action. The IKS master is run/managed by IBM, but the audit events are more kube-centric than IBM Cloud centric.
In any case - this entire project is a work-around to get the data out of the IKS master API server and get it into the customers hands. It is reasonable to allow the customer to send that data where they want.